RE: [stellation-res] Stellation on Mckoi

["Jonathan Gossage" <jgossage@xxxxxxxx>]

Comments are embedded:

> -----Original Message-----
> From: stellation-res-admin@xxxxxxxxxxxxxxx
> [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> Chu-Carroll
> Sent: Tuesday, July 22, 2003 7:27 PM
> To: Stellation-res
> Subject: RE: [stellation-res] Stellation on Mckoi
>
>
> On Tue, 2003-07-22 at 18:48, Jonathan Gossage wrote:
> > >
> > > Basically, we just plain got the Location stuff wrong. The original
> > > idea was to have something URL-like for specifying repository
> > > locations. But it just never worked well. Even if the
> command-line code
> > > were the cleanest, most comprehensible code in the world, the
> > > whole location notation would still cause endless confusion and
> > > grief. In the next version of the command line, we're going to
> > > discard location strings in favor of multiple command-line
> > > parameters.
> >
> > In fact, the location problems are the least of the problems with the
> > command line.There are also some absolutely horrendous
> performance problems
> > with workspace management. Last year, after I had got the MySql
> stuff going,
> > I started to do a high volume benchmark involving about 200K
> directories and
> > about 1.5M files. It took over 30 hours simply to add the files into the
> > workspace with the "add" command. I know why this happened but
> it would be
> > hard to fix in a robust manner with the current implementation.
> I have some
> > suggestions regarding the command line but I will present them
> in a separate
> > post.
>
> I think that pretty much everyone is in complete agreement here. The
> current command line code is a total disaster area, and it's
> completely beyond our abilities to fix it. Replacing it is the
> way to go.
>
> To come to the defense of the author of that code (since he no
> longer subscribes to the list, and thus can't defend himself),
> the command line code was never really intended to be kept. The
> initial implementation of it was written before we really understood
> what we wanted from a workspace. It was initially tossed together
> just to give me a way to test the back-end. But the initial
> implementation of it was *really good*. I know that's kind of hard to
> believe looking at it now. But it was good enough that instead of
> discarding it as we originally expected, we decided to keep it.
>
> That initial design was *really* good. I was thrilled when I
> saw it. It was a beautiful, clean design; literally good enough
> to be used as a textbook example of software design.
>
> Unfortunately, the rest of its history is a textbook example of
> the typical problems of software evolution: from the time the initial
> implementation was finished, the guy writing never gave *design* a
> moments thought. It just kept growing in a totally haphazard fashion,
> totally out of control, until it degenerated into total chaos that
> no one but its author has any hope of understanding.
>
> There's some *astoundingly* inefficient stuff going on in there.
> Bizzare amounts of line-by-line IO, file copying, archive generation,
> and logging. There are times when (I think) the same change involves
> making three different copies of the file in different places.
>
> The current tentative plan is to just leave the current command-line
> code alone as much as possible: do absolutely necessary bugfixes,
> but nothing else. Meanwhile, we're trying to write the Eclipse
> workspace plugin so that it can be used by either a GUI driver inside
> of eclipse, or by a standalone command-line driver. This is totally
> new code, with not a single line from the old command-line. This
> will replace the current CLI once it's finished.
>
I would like to take a stab at a command line interface. Given the direction
you are taking the core system, there seems to be room for customized CLI's
if ever necessary.
Initially, I would like to see a CLI that plays nicely with the Eclipse
workspace, i.e. it can do checkins and checkouts from/to the Eclipse
workspace even if the workspace is concurrently being used interactively.
This will allow it to be easily used from within tools like Ant, which
themselves may be running from within the Eclipse environment. This could be
done by having the CLI try to connect to the core Eclipse Stellation support
and if it was not found, start a headless Eclipse environment to run
standalone.

In the initial CLI, I believe we should concentrate on working within the
Eclipse environment, rather than trying to provide a complete standalone
workspace for other CLI tools to integrate with. Initially I see the CLI as
a tool to be used by system builders etc., rather than as a full function
standalone tool. Full standalone functionality can come later once demand,
and hopefully resources, show up.

In addition, it may make sense to write a properly integrated Ant task to
improve the use of Stellation in Ant based environments.

Would you be interested in me preparing a full functional spec for this
chunk of work?

Regards

Jonathan Gossage

Personal Email jgossage@xxxxxxxx
Business Email jonathan@xxxxxxxxxxxxxx