Re: [stellation-res] Initial Eclipse client APIs posted for discussion

[Dave Shields <shields@xxxxxxxxxxxxxx>]

On Thu, Oct 17, 2002 at 05:19:23AM -0400, Jonathan Gossage wrote:
> > >The Svc workspace already has a notion of "workspace state" which is
> > >locally persistent, motivated by many of the reasons you cite.
> > >We've since concluded this is not such a great idea:
> > >* the local "workspace state archive" is basically a
> > >"lightweight repository"
> > >   - but not exactly.
> > >* the two entities do *not* have identical behavior, leading to confusion
> > >   and additional code maintenance.
> > >* there is a significant performance hit related to saving the
> > >*entire* project
> > >    workspace state to a local zip archive before most
> > >Stellation operations.

Not true. The *entire* workspace state is not saved to a single zip archive, only
the project file and the compressed form of any artifacts not previously archived.

> > >   A local repository, hosted on a local database, would likely
> > >do a better

Why should we have to use yet another database to save state while preparing a new
revision? The save/restore is mainly meant to provide an "undo" mechanism using the 
client filesystem without the need to install any additional software. 

> > >
> > >   job.  Also - the Eclipse "local resource history" mechanism
> > >fills some of
> > >   the same needs; it should be possible to leverage it even more as the
> > >   Stellation Client develops.
> > >Switching between "local" and shared repository" mode will hopefully
> > >be as simple as rebinding an ScmAccessPoint  to a different repository.
> > >
> I agree with you that the current workspace implementation is haevy-weight
> and costly in terms of resources. 

Assuming the Eclipse "local resource history" will do the
job assumes the user is willing to always run from within Eclipse.
This is also "heavy-weight and costly in terms of resources".

Since you both agree the current workspace code is "heavy-weight and costly in resources",
any suggestions on improving it would be welcomed, though I would prefer to put any
changes that won't have major impact on hold until alpha release is out.


dave

-- 
Dave Shields, IBM Research, shields@xxxxxxxxxxxxxx.