Excuse me butting in, and Hi.


Doug Way <dway at mat.net> wrote:
> 
> On Thu, 21 Oct 1999, Stefan Matthias Aust wrote:
> 
> > The result looks very much like ENVY - if done right.  Where's the
> > advantage?  Well, you can build on proven technology which already has a
> > working client server mode.  You omit envy's
> one-big-unknown-contents-file.
> >  It's no closed source and -- hopefully - less expensive.
> > 
> > And if you don't go for ENVY (Doug, I'd really like to hear your
> arguments
> > why you think ENVY's approach is better) but follow by ideas about what
> > sharing units of work means, CVS looks even better.

ENVY's advantages over a CVS type repository, namely: 
* the speed at which the precompiled bytecode can be linked into your image
* the Smalltalk-centric way of doing things (non-intrusive - once you're familiar)
* (very)Comprehensive and flexible UI


can be matched by CVS - look at Team/V - but by that stage you've reimplemented ENVY.

> I didn't rule out that an implementation based on CVS was possible.  I was
> mainly concerned about the implementation issue of using a file to
> represent each method... this would result in tens of thousands of files
> to represent a regular Squeak image.  This seemed like it might be a
> problem... although maybe it wouldn't be a big deal.  (I suppose there are
> CVS repositories out there containing tens of thousands of files...)
> 
> The fact that CVS is open source and already handles client server stuff
> is a big plus.

That's true - however gluing it to Squeak in a way that doesn't kill the rapid-feedback thrill of Smalltalk or bloat your image may mitigate the advantage of available source.

How about pushing more of the grunt work down to the client's image? Squeak has some remarkable and promising abilities in terms of Object<->Disk and ImageSegment<->Disk storage. If we could leverage those and others, we could have the server be as dumb/lean/simple as possible - a la Tensegrity or Objectivity. Even adapting CVS may be possible - without the overhead of Team/V, hopefully - but I imagine that the storage mechanism could be pluggable; all it needs is to be shareable, lockable, commitable and back-out-able. And many client-based OODBMSs are quite lightweight...

....yeah, I know. I'm suggesting we tackle the complexity of building an OODBMS to avoid the complexity of building a CVS wrapper - it's just that an OODB would be useful for SO many other things  : )

> 
> Also, I'm not totally stuck on doing things purely the ENVY way... I was
> mainly advocating versioning (tracking) down to the method level.  (So, if
> you wanted to, you could look up all the versions/editions of a particular
> method in the repository, via a tool of course.)  You could still have
> changesets, which are then a list of pointers to method versions.
> 
> > >And this is what I was heading for. I thought of an ENVY-like server in
> > >a LAN or even WAN written completely in Squeak that manages one change
> > >file (with some additional information and pointering) and thus
> replaces
> > >the image and changes files of all its clients.
> >
> > I don't like the idea to replace something that works.  One of ENVY's
> > drawbacks is that you need a permanent connection to its repository.  I
> > prefer a checkout/optionally lock/checkin approach which allows you to
> work
> > "unplugged".  Assume you simply want to try something out which shall
> not
> > affect any other code.

(Actually, ENVY lets you do exactly that, really easily.)

> I agree with you here... there should definitely at least be a mode in
> which the repository connection is optional.
> 
> Also, ENVY does that thing where every method which is ever accepted is
> stored in the repository... that's nice to have sometimes, but definitely
> not a crucial feature.

Ahh, there's one advantage of ENVY I forgot:
* Totalitarian control over the shred image

You're right, it can be a drag - but I've never seen anything strip a deployable image down to nothing like ENVY - it tracks every message send - and it's dead easy.

> > Keep in mind, these are minimal requirements but I'd like to see these
> > relalized then endless talking about what the complete set of features
> is -
> > if I'm allowed to choose ;-)
> 
> Fair enough... perhaps a CVS-based repository which stored changesets as
> files would be an okay start.  (Storing methods as the smallest unit is
> still the ultimate goal, though, I'd say.)
> 

Yes, it's a big question - lots of work whichever way you go. Is there an open forum for discussing this? Perhaps there's someone with access to resources that could help cross a few bridges. (MinneStore? JCVS? mySql and Mini-External-ImageSegments?) I'd sure like to be involved.

....just my 2.165 cents worth...

 - Robin


> - Doug Way
>   EAI/Transom Technologies, Ann Arbor, MI
>   http://www.transom.com
>   dway at mat.net, @eai.com