RE: [stellation-res] Stellation on Mckoi

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

On Tue, 2003-07-22 at 20:47, Jonathan Gossage wrote:
> 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?


Sounds absolutely terrific, and well in line with what Jim and
I have been discussing. I'd be thrilled to see a spec for it.

There's a good chance that our server will be up in another day or
so, and once it is, we'll have a wiki where we can hash out things
like this.  I've been using an internal wiki for writing notes
as I study Eclipse guts, and I've found it's an extremely effective
way of organizing your thoughts as you put together a document.


	-Mark