RE: [stellation-res] Location option

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

On Mon, 2002-12-30 at 21:02, Jonathan Gossage wrote:
> > >-----Original Message-----
> > >From: stellation-res-admin@xxxxxxxxxxxxxxx
> > >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> > >Chu-Carroll
> > >Sent: December 30, 2002 10:22 AM
> > >To: Stellation-res
> > >Subject: Re: [stellation-res] Location option
> > >
> > >
> > >On Mon, 2002-12-30 at 12:49, Jonathan Gossage wrote:
> > >> I have some conceptual problems with the CLI "location"
> > >option. I find the
> > >> syntax is arbitrary and somewhat painful. It forces order
> > >dependencies in
> > >> the constituent parts and depending on the target the order of
> > >the parts
> > >> changes. It is also a little ugly to parse in code.
> > >>
> > >> I would like to suggest that this option be replaced by a set
> > >of options,
> > >> one for each of the parts. Thus you would wind up
> > >> with --host, --port, --protocol and --dbname options. Since in
> > >most cases
> > >> only one of these options needs to be specified, (the defaults are
> > >> sensible), the user interface is simplified.
> > >
> > >I agree that the current locations are really pretty ugly, and we should
> > >really do something to clean them up.
> > >
> > >My main concern is adding too many options for overlapping things. The
> > >original reason for the location string was that different databases
> > >need different information to identify a local database; and we may add
> > >different protocols, each of which might need different information to
> > >establish a connection. To cover all of this potentially explodes the
> > >number of options, and the kinds of checking that needs to be done to
> > >ensure that the set of options provided don't conflict in any way.
> > >
> > >One alternative would be to switch to using URLs. That gets rid of a lot
> > >of the arbitrariness of the locations, and Java has builtin support for
> > >parsing URL format stuff in java.net.URL, so it gets rid of the parsing
> > >issue.
> > >
> > >	-Mark
> from a user point of view URL's are almost as bad. You still need to
> remember an arbitrary syntax but I grant you that at least the elements will
> appear in the same order every time.

It's ugly, but it's a consistent syntax that is at least familiar
looking.

> As it has worked out in practice, there are only four pieces of configurable
> information and they can be potentially present in all location options.

No, they can't. For example, if you're using a "postgres:" location,
there can't be a port specified. If you specify a firebird location,
then the port can be specified. If you do a DB2 connection, then you
need a database name, and a namespace name, and the name of the db2
instance. If you specify a namespace option for postgres, it should
be an error.

That's my worry. Note that I'm not taking a strong position here. I
dislike the current location strings, and agree we should do something
to fix them. But I'd strongly prefer to work through all of the pros
and cons of the options carefully, so that this time, we get it right,
and don't need to go back and change it again a year from now.

I favor the URLs slightly, for two reasons:

(1) They're a lot faster to type. I'd rather type
"-location=stellation://stellation.eclipse.org:6060/myrepo" than
  "--access=remote --host=stellation.eclipse.org --port=6060
--dbname=myrepo".

(2) They are a reasonably familiar syntax, so people won't have too much
    trouble with them. 

On the other hand, the multiple options aren't that much more onerous,
and they are easier to read. So I'll happily go along with whatever 
consensus we wind up with.

> However, another option has just occurred to me. What if we were to have the
> user specify a database name only and extend Svcadmin to store complete
> information for configuring the database connection under the database name.
> The information could be stored in .svcrc in XML format and all the user
> would need is to supply a simple database name.

This won't work. "svcadmin" is intended for use only by Stellation
administrators. If you're just using a Stellation client, you shouldn't
even have to install svcadmin. I'd strongly prefer either the multiple
options or URL approach to something that required using svcadmin, or
some corresponding command, in order to configure your ability to access
a repository.

> As for Linux, I seem to be the mirror image of you with respect to Windows.
> I have no problems setting things up in a Windows environment but I spend
> hours poring through documentation before I can do the simplest thing in
> Unix. Quite frankly, I think I will be more useful to Stellation if I stick
> to what I know well at this point.

As I said, I think it's a matter of what you're familiar with. You know
how windows is put together, and where to find the magic dialog that
lets you set up/fix a configuration. I know how Unix is put together,
and where to find the magic files that need to be edited to set up/fix
a configuration. 

Do whatever you're comfortable with. If you want to stick with the
windows side, believe me, no one will complain: we really need 
someone who understands that world.

	-Mark

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