On Tue, May 09, 2000 at 02:33:57PM +0100, Dr A V Le Blanc wrote:
> Well, I've given my little presentation about Coda for the first time.
> I intended to give the presentation using Star Office with the
> files (both Star Office and the presentation itself) in Coda,
> but the display at the venue was unable to show graphical output
> from my borrowed notebook.  For those of you who are interested,
> a web-version can be found at http://www.mcc.ac.uk/~zlsiial/coda/.

Very nice and detailed presentation.

| I'm quite happy with the notion of having ordinary users use Coda on
| their workstations; I'm less at ease at the thought of thousands of my
| users trying to run in disconnected mode,

That's exactly how I feel when people ask me about Coda's stability. The
nightmare that haunts me most is the image of 1000's of people dialing
in overnight (running weakly connected), and the amount of conflicts that
would have to be cleaned up in the morning.

> At the conclusion of the talk, I make some suggestions, some smaller
> and some larger.  I am willing to help with some of the smaller
> ones, and I'd like to propose the larger ones for discussion here.
> 
> Smaller suggestions:
> 
> The documentation needs revising.

Adrian has been going through the Coda user and administrators manual
over the past 2 weeks and converted it to DocBook while he was at it.
We'll put the new version online and into CVS soon. Manual pages are
still quite outdated.

> I'd like to see a ca/copyacl subcommand in cfs.

That shouldn't be too hard considering how setacl is implemented
'getacl(dir)/setacl(dir)', so copyacl would become 'getacl(srcdir)/
setacl(tgtdir)'

> I'd like to see an option to kclog which allows you to specify
> a token lifetime shorter or longer than the default, being
> anything from a few minutes to a few months.  This involves changes
> to kauth2 as well as to kclog.

My guess is that a user would always try to get a token for as long as
possible, so maybe just changing kauth2 to have per user token lifetime
policies. My other idea is in the direction of a clog-daemon, which
Venus can query for the user's `secret' when a token expires.

> Slightly longer suggestions:
> 
> I'd like to see something like AFS's ptserver, volserver, and buserver;
> that is, some way of handling users and groups, volume status, and
> backup configuration remotely.  I realise that pdbtool is a relatively
> new piece of Coda, but I don't think it goes far enough.  Moreover,

We've experimented with LDAP for this, and although it looks promising
we did have several problems.
 
- Libc conflicts between Coda's use of LWP and OpenLDAP's pthreads.
  Also, the pthreaded version of LWP is definitely not stable enough to
  be used to avoid these conflicts.
- Connection setup times is substantial, and failover to another LDAP
  replica server is very poor or non-existent. This might one day be
  `solved' by connectionless LDAP, which is currently not implemented in
  OpenLDAP.

On the positive side, the caching works well and the flexible query
mechanism allows for very nice searches. Using LDAP also leverages off
other development. No need to design our own GUI for managing the
database, users can be given permission to create/manage their own
groups within the framework, etc.

> Finally, I have a question.  Is it a good idea to replace the
> single SCM with some sort of quorum voting as in AFS?  It sounds
> like a good idea at first blush, though I am concerned by the
> problems which it has in practice in AFS; I'd not like to see
> Coda's incredible resilience impaired by tacking on something
> that doesn't quite work as it should.

The system as a whole doesn't really rely on the SCM except the
modifications to user/volume databases that are then shipped to the
other machines. When the SCM dies, either another machine can take it's
place (my guess is that it should have most of the required data already
if not all of it), or adding/deleting users and volumes is temporarily
not possible. 

Hopefully at some point an existing configuration database or directory
system, like ACAP or LDAP, can be used to replace the existing
`replicated databases pushed around by updateclnt/updatesrv' model.

Jan