RE: [stellation-res] Stellation on Mckoi

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> -----Original Message-----
> From: stellation-res-admin@xxxxxxxxxxxxxxx
> [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Mark C.
> Chu-Carroll
> Sent: Tuesday, July 22, 2003 9:04 PM
> To: Stellation-res
> Subject: RE: [stellation-res] Stellation on Mckoi
>
>
> 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.

Sounds good. I think a Wiki could be a really neat way of driving specs.
development. That way, one person can be the driving force but everyone can
contribute to the evolution of the specification with the final document
itself being part of the Wiki.

Regards

Jonathan Gossage

Personal Email jgossage@xxxxxxxx
Business Email jonathan@xxxxxxxxxxxxxx