Regards
Jonathan
> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Jim Wright -
> >IBM Research
> >Sent: October 10, 2002 6:07 PM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: RE: [stellation-res] Initial Eclipse client APIs posted for
> >discussion
> >
> >
> >Hi Jonathan --
> >
> >First, let me apologize for not responding sooner. I've been waiting
> >for time to write a more detailed reply than "thanks for the input,
> >I'll get back to you soon".
> >
> >So - thanks for the input!
> >
> >I really appreciate the thought that went into your detailed "Near Term
> >Stellation Architecture" doc. I certainly agree that an overall
> >architecture
> >doc is sorely needed, and should be one of the outputs of the current
> >Eclipse client API work.
> >
> >In the current API design, the breakdown is roughly as follows:
> >
> >** Scm "Client Core":
> > IScmProject [ has IScmArtifactMap and BranchImage]
> > IScmFactory
> > IScmAccessPoint
> >
> >The Client Core provides the fundamental conduit between a
> >local Stellation-managed Eclipse project and the associated
> >Stellation repository.
> > Factory - builds ScmProjects and ScmAccessPoints
> > AccessPoints - required by ScmProject; also useful
> > for getting information from a repository, or (perhaps)
> > remote repo administration.
> >
> >** Mapping between Eclipse and Stellation resources
> >
> >Eclipse IPaths are mapped to Stellation ArtifactIDs by the
> >IScmArtifactMap for a given IScmProject.
> >Eclipse IResources are mapped to IPaths by the ScmProject.
> >Note that the IScmArtifactMap does *not* alter the local
> >Stellation project image; local project image manipulation
> >is actually performed by IScmProject.
> >
> >Jonathan's diagram implies that the Eclipse-to-Stellation
> >mapping is performed *outside* of the Client Core (which
> >Jonathan called "Stellation Client Manager"), within
> >a "Stellation Repository Manager" entity. The actual
> >resource-level mapping is currently performed *inside*
> >the Client Core. So are basic team management
> >facilities (checkin, checkout, fork, move, rename, delete...).
> >
> >** Additional Stellation Client Components.
> >
> >The complete "Stellation Client for Eclipse" will include
> >a number of components (this is not a complete list):
> >* Resource listeners for updating the local Stellation project
> >image when Eclipse project resources change (this is already
> >in the current plug-in).
> >* Support for using the Eclipse (CVS) visual merge editor
> >with Stellation (not yet implemented).
> >* Resource Decorator support (not yet implemented)
> >* Project properties pages, Workspace Preferences pages
> >(some are present in current plug-in).
> >
> >These components are clearly not part of the 'Client Core'.
> >I also expect that, over time, various analytical and other
> >tools will be built on top of the Client Core.
> >
> >For fine-grained support, we'll need components for Java editor
> >integration, Outline view integration, Query specification and
> >fragment property inspection etc. etc. Further details are
> >given in the "Fine-Grained Roadmap" doc up on our website.
> >
> >** Stellation Workspace and Command Line
> >
> >The 'Workspace' notion stems from the original command-line
> >client. The current Eclipse client API doesn't use it, partly
> >because IScmProject seems sufficient, and partly to avoid
> >confusion with the Eclipse Workspace.
> >
> >I have just added support to IScmProject for locally-persistent
> >properties; these are persistent across multiple Eclipse sessions on
> >a given workstation, but are not stored in a Stellation repository
> >with regular project data/metadata. The immediate motivation
> >was for storing the "new Artifact ID counter" value (stored by
> >Svc in workspace.xml). Between the project-related metadata
> >already stored by Eclipse and the IScmProject locally-persistent
> >properties, I'm hoping that a distinct 'ScmWorkspace' class
> >won't be needed.
> >
> >Your notion of a "Stellation Workspace" seems very close
> >to the current BranchImage class (stellation.repos.BranchImage).
> >A BranchImage represents the current contents of a Stellation
> >project, in terms of artifacts, with no reference to file-system-
> >specific constructs of any kind. While the current Svc
> >Project class is derived from BranchImage, IScmProject
> >(so far) contains an instance of BranchImage:
> >a) To me, the relationship between a project and a particular
> >branch image is "has-a", not "is-a".
> >b) The ScmProject gets down'n'dirty with the Eclipse model
> >of resources and the file system. The BranchImage is completely
> >divorced from such messiness. I'd like to keep it that way.
> >
> >You've suggested a Stellation Command Line Utility which uses
> >IScmProject. This is certainly possible (the Eclipse framework
> >supports non-GUI command-line applications). However, such
> >a client would need to use org.eclipse.core mechanisms
> >for file system manipulation (IPath, IResource, etc)
> >rather than standard Java File and I/O classes used by the current
> >Svc client, since IScmProject is (currently at least) hardwired to
> >use the Eclipse resource model.
> >
> >It may be possible to factor out "essential" Stellation client
> >functionality
> >from IScmProject, into a form that would be shareable between an Eclipse
> >client and an Svc-like client, but that's outside the scope of my current
> >work. It could happen in the next pass (when we add full fine-grained
> >support to the Client Core), but frankly I'd rather see development of
> >a fully Eclipse-based command line client. (In fact, I'd *love* to see
> >that happen, and would be happy to refactor "Core Client" code
> >if necessary to better support shared use by Eclipse and command-line
> >clients.)
> >
> >** "Persistent Stellation Workspace"
> >
> >I'd rather not go that way, for several reasons. The primary one
> >is that most of your proposed functionality could be accomplished
> >by using a local Stellation repository, once we support replication
> >between Stellation repositories (definitely one of our goals).
> >Why build and maintain two complex entities to do what's basically
> >the same job?
> >
> >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.
> > A local repository, hosted on a local database, would likely
> >do a better
> > 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.
> >
> >If you want to build an Envy-like workspace implementation on
> >top of Stellation for other reasons, please post more details about
> >those reasons. I suspect (hope) that the upcoming fine-grained
> >support will go a long way towards addressing "workspace Envy".
> >
> >Thanks again for the input - looking forward to your reply.
> >
> >Best regards,
> >Jim
> >
> >At 11:06 PM 10/6/2002, Jonathan Gossage wrote:
> ><snip>
> >>Your documents prompted me to make a start at a document that I feel is
> >>missing from Stellation, namely an overall architecture document that
> >>describes the various Stellation components and how they fit
> >together. So I
> >>have made a first attempt at putting such a document together,
> >and in the
> >>process I have identified a possible architecture for Stellation that is
> >>sufficiently decoupled so as to be easy to maintain in the future as
> >>requirements change.
> >>
> >>Even if you find the specific suggestions that I have made to be
> >>unacceptable, I think that the idea of the document is
> >important and that
> >>the team should jointly flesh out the content based on whatever overall
> >>architecture is agreed on.
> >>
> >>The document is in HTML format, but I have not had a chance to verify it
> >>with a variety of browsers and have not had any chance to look
> >at it under
> >>Linux. However I have verified that it is displayable using Mozilla 1.1.
> >>
> >>Regards
> >>Jonathan
> >>
> >>Personal Email
> >>jgossage@xxxxxxxx
> >>
> >>Business Email
> >>jonathan@xxxxxxxxxxxxxx
> >
> >--
> >Jim Wright, IBM T.J. Watson Research Center
> >*** The Stellation project: Advanced SCM for Collaboration
> >*** http://www.eclipse.org/stellation
> >*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
> >jim.wright@xxxxxxx
> >
> >_______________________________________________
> >stellation-res mailing list
> >stellation-res@xxxxxxxxxxxxxxx
> >http://dev.eclipse.org/mailman/listinfo/stellation-res
_______________________________________________
stellation-res mailing list
stellation-res@xxxxxxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/stellation-res
