Re: [stellation-res] Command line configuration specification

["Mark C. Chu-Carroll" <mcc@xxxxxxxxxxxxxx>]

On Thu, 2003-01-09 at 17:55, Jonathan Gossage wrote:
> I have just checked in a specification document for the command line
> configuration stuff I proposed. It is misc/doc/specs/configuration.txt. Your
> comments will be most welcome before I proceed to implementation.

I've got a couple of comments. It mostly seems good, but there are
a few points where I found things either confusing, or where there are
some details that I think were off.

- There are a bunch of places where you say something along the
  lines of "this value is required", and "this defaults to X". (For
  example, the port that the client will use to connect to a server.)

  I understand what you mean, but I find the wording very confusing.
  When you say the value is required, it sounds like it's something
  that the user/administrator is required to explicitly specify; saying
  it has a default sounds like the system sets it automatically if it
  isn't explicitly specified. 

- In the client connection information, you say that the port that the
  Stellation server listens on is   database specific. It isn't: it's
  server specific - but not database specific. What database you use
  shouldn't have any effect on what port the Stellation server listens
  on. 

- You ask if we should merge the suffix and filetype stuff. I think
  so. It's easier to specify a suffix than a regexp, which is, I think,
  why the suffix stuff originally went in separate from the regex. But
  once there's a decent config tool, there's no reason to not unify it,
  and let the tool gloss over - that is, provide an option in the tool
  for saying "any .foo file is binary", and have the tool expand that to
  the regex ".*\.foo".

- I don't think that the Eclipse team plugin should read the command
  line config file. There's too much overlap between what we put in
  those files, and stuff that Eclipse does itself. I think it's going to
  get too complicated. Instead, I think we should let the Eclipse plugin
  get its config from the Eclipse prefs, and store it in the Eclipse
  metadata location.

- I'm pretty sure that MySQL has a notion of a database name, and so
  there should be an option to specify that.

- In the Server-connect element of the config file: the intention is
  to have a server listen on a single port: the login and subscription
  process is how we distinguish a child server from a client. So there
  shouldn't be a distinct port for accepting connections from children.

- I'm a bit skeptical about encrypting the database admin password. The
  question is, how do we encrypt it? I can't think of a way that won't
  be easy to reverse engineer and determine the password. (For example,
  we could hardcode a password when we compile the server, but then that
  password can be found by looking at the .class file. We could encrypt
  that, but then it's still not too hard to find a way to figure out how
  we did that, and get *that* password. It seems to me that ultimately,
  unless we require the administrator to specify a password when they
  start the server (which precludes automatically starting servers),
  then we are ultimately relying on the fact that the config file is
  secured. Putting the encryption in is giving people a false sense of
  security that they don't really need to be so careful of protecting
  their server config file.

	-Mark

-- 
Mark Craig Chu-Carroll,  IBM T.J. Watson Research Center  
*** The Stellation project: Advanced SCM for Collaboration
***		http://www.eclipse.org/stellation
*** Work: mcc@xxxxxxxxxxxxxx/Home: markcc@xxxxxxxxxxx