(Illustration by Gaich Muramatsu)
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/. 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. I'd like to see a ca/copyacl subcommand in cfs. 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. 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, the ability to have users create and manage their own groups is too good to miss. Also, if the mechanism is such that you need System:Administrators tokens to do certain things, that would be all the better. I'm uneasy as it is about having users able to mess up things on a client with some of the more dangerous cfs commands; I wish these were restricted to local root or something, at least on machines where there may be several Coda users at the same time. 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 paper concludes that Coda may be ready for production use in limited cases, where there is (a) not a lot of data or users, and (b) more need for high availability than for ease of administration. I also warn that it's not easy for unskilled users to install and run. The paper concludes with a note of thanks to all of you, and to Jan Harkes in particular for all the help I've had here. -- Owen LeBlanc_at_mcc.ac.ukReceived on 2000-05-09 09:35:53