RE: [stellation-res] Location option

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----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.

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.

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 would make it easy for a single Stellation server to support multiple
repositories and indeed different database platforms at the same time.

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.

Regards

Jonathan

Personal Email
jgossage@xxxxxxxx

Business Email
jonathan@xxxxxxxxxxxxxx