[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [stellation-res] Initial Eclipse client APIs posted for discussion
|
Sorry to be so long getting back to you. I have interpolated comments in
your discussion.
> >-----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...).
What I was trying to describe here was an architecture that was independent
of any particular IDE or other client of Stellation so to maximize the ease
of integrating Stellation with potential client apps or environments. The
idea was to map between specific client environments and Stellation in proxy
classes so that the "Client Core" was not dependent in any way on any
particular Stellation client. To me Eclipse is simply one client for
Stellation, even if a major one.
> >
> >** 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.
I agree and feel that the Eclipse/Stellation integration *should* use the
Eclipse workspace as its' workspace target,
> >
> >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 will get no argument from me on that issue. To me the ScmProject is the
interface to the Eclipse world and the branch image is the Stellation view
of the world.
I was considering the "Stellation Workspace" to be an abstraction of a
potential family of concrete workspaces that would be used where the
Stellation clients had no particular notion of a workspace and just
interacted with the local file system. If you want to use Stellation in a
standalone environment then you need an interface to the file system similar
to that which exists in the current command line utility.
> >
> >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.
> >
I must not have made myself clear. I was considering the command line
utility to be a client of Srellation in exactly the same way as Eclipse is.
My thought was that there would be a proxy module for each client that
translated the internal "Stellation Client Core" view into a suitable view
for for the particular Stellation client. These proxies would access the
"Client Core" through a well defined interface and would insulate the core
from any outside contamination.
> >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.)
> >
Right. What I am trying to do is to get agreement on a long term
architecture that will minimize the need for major restructuring down the
road as other potential clients materialize. The longer you leave this the
harder it will be to do. But I also understand your need for short term
goals to meet immediate requirements. What I hope we can do is to come up
with a long term architecture that we can work towards as time permits. I
think we are close enough and the current core is good enough that such
refactoring will not be too difficult.
> >** "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.
> >
I agree with you that the current workspace implementation is haevy-weight
and costly in terms of resources. However there is a need to be able to
simply view the local file system as a place to stor Stellation resources
where they can be accessed by traditional tools. I don't think this support
needs to be any where as complex as at present. To me all the smarts in
terms of integrity etc. should be built into the Stellation 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".
What I was really thinking about here was the ability to have the option to
use a local Stellationn repository as the persistent Eclipse workspace for
Stellation managed resources, avoiding the need to use the local file system
at all. Eclipse already provides the capability to implement alternate
persistent storage implementations so users could have a choice. I think
that as you move into fine grained artifacts and even more once the need to
store AST's as persistent structures arises, that working directly in a
local Stellation based repository will become very attractive.
> >
> >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
