RE: [stellation-res] Client-server organization

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> >Chu-Carroll
> >Sent: January 25, 2003 9:32 PM
> >To: Stellation-res
> >Subject: Re: [stellation-res] Client-server organization
> >
> >
> >On Sat, 2003-01-25 at 14:43, Jonathan Gossage wrote:
> >> At the moment, clients can run either talking to a Stellation server or
> >> directly to a local database. I seem to remember some talk
> >about wanting to
> >> regularize this and provide an environment where all access
> >from clients to
> >> a repository goes through the Stellation server.
> >>
> >> Personally I prefer this mode as I don't particularly like
> >multiple access
> >> modes unless there are compelling benefits that come with them.
> >
> >I strongly believe that we should be presenting the system exclusively
> >as a client-server system. The server is sufficiently lightweight that
> >even if you're a single user always working on the same system, it's
> >not going to be a burden to run a Stellation server. There are potential
> >race conditions that are *deliberately* not fixed in the local access
> >mode. (The way that remote access works, the server obtains a
> >local-access repository handle. The kind of synchronization that would
> >be necessary to eliminate the race conditions in local access would
> >be complicated (especially in Postgres, due to some rather nasty
> >bugs in postgres JDBC - and for the moment, postgres remains our
> >primary DB), and would have a significant adverse effect on the
> >performance of the remote access.)
> >
> >This is something that I've been pushing for a long time, but others
> >still seem to find the local-access mode compelling. I don't really
> >understand why - but for some reason, many people find the act of
> >having to run a server to be an unreasonable burden.
> >
> >	-Mark
> >
> >
The work I am doing right now on the new configuration support strikes right
at the heart of this issue. Can I take it, unless we hear strong objections,
that I should implement the configuration process with a pure client/server
approach?

Regards

Jonathan