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 11:28 AM
> >To: Stellation-res
> >Subject: RE: [stellation-res] Location option
> >
> >
> >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.

I don't think I explained myself properly. To me, establishing the
connection parameters for a specific repository is an administrative
function that should only have to be done once for any given repository.
Consider the normal operation of Stellation where we have a server that can
support one or more repositories. In this case once the back end database is
established, the connection parameters will only change on a very infrequent
basis. Clients should simply have to say that they wish to access a given
repository without concern for the gory details that make it happen.

It makes sense for the administration utility to have direct "local"
connection to the back-end database for a repository but not for normal
clients, whether command line or IDE based. So what I would like to see is a
connection configuration capability added to the administration utility that
can be run once to establish the connection paramters. This configuration
utility would understand the connection information requirements for each
supported database platform and would only request relevant information for
that specific platform. This eliminates the problem of determining which
connection parameters are relevant for which platform.

Initially this capability should be provided in a command line version, but
eventually I would like to see both command line and GUI interfaces to a
common administrative core.

The final piece of the puzzle is to provide a means for clients to specify
and save repository connection information (i.e. the host name of the
repository server and the port) each indexed by the repository name. Given
this capability, a user need never specify anything other than the name of
the desired repository, and if the user only accesses a single repository,
then nothing should need to be specified.

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

For the moment that seems to be the best approach.
> >
> >	-Mark
> >


Regards

Jonathan

Persoanl email
jgossage@xxxxxxxx

Business email
jonathan@xxxxxxxxxxxxxx