[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [stellation-res] Code Audit for Workspace package
|
> >-----Original Message-----
> >From: stellation-res-admin@xxxxxxxxxxxxxxx
> >[mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Jim Wright -
> >IBM Research
> >Sent: September 3, 2002 2:42 PM
> >To: stellation-res@xxxxxxxxxxxxxxx
> >Subject: RE: [stellation-res] Code Audit for Workspace package
> >
> >
> >Hi Rodolfo,
> >
> >I'm glad you're interested in the core scm API, and making it
> >work with SWT.
> >
> >At 02:19 PM 9/3/02 -0300, Rodolfo M. Raya wrote:
> >>On Tue, 2002-09-03 at 13:59, Jim Wright - IBM Research wrote:
> >>
> >> > As is probably obvious, switching over to a new {debugged,
> >thought-through}
> >> > command mechanism will delay updating the UI code to use the new
> >> > workspace APIs. I'd like to know if the additional delay
> >(1-2 days?) is
> >> > problematic for anyone; if so, I can probably update the the relevant
> >> > stellation.scm.core without having to back out of the in-progress
> >> > command mechanism changes; the two chunks of code are fairly
> >well isolated.
> >>
> >>Hi,
> >>
> >>It doesn't really matter how long it takes if you do a good job
> >>separating the command line interface from Eclipse specific ui.
> >
> >The command mechanism I'm working on is different from the current Svc
> >command-line interface. My in-progress mechanism fits between
> >stock Eclipse
> >command handlers (e.g. classes implementing IAction,
> >IObjectActionDelegate,
> >IWorkbenchWindowPulldownDelegate, etc.) and model-level Stellation
> >functionality (e.g. stellation.scm.model.ScmFacade.Checkin).
> >
> >There is a separate chunk of work concerned with updating the
> >current Eclipse
> >GUI code to talk directly to Projects, BranchImages, Artifacts, Agents,
> >Inputs, and Outputs. Currently, ScmFacade, ScmEnvirons, InfoLister and
> >related classes talk fairly directly to core workspace code (the same
> >classes used by the Svc command-line driver). This worked okay
> >(sort of)
> >as a quick'n'dirty approach, but there's way too much
> >command-line-specific
> >gunk in there. Furthermore, to get fine-grained support working, the
> >Eclipse UI code *has* to talk directly to Projects,
> >BranchImages, Artifacts
> >and the like.
> >
> >The picture I'm thinking of looks something like this:
> >
> >(a) Stock Eclipse UI command handlers (IAction,
> > IActionDelegate, etc.)
> > \
> > (b) stellation.scm.ui.action 'ScmCommand' objects
> > \
> > (c) stellation.scm.model 'Fine-grained-image' APIs and wrapper
> > classes
> > \
> > (d) stellation.repos core functionality and
> > stellation.workspace.Project
> > /
> > /
> >(e) Svc command-line driver and helper classes
> >
> >
> >(a) is a set of very generic code fragments following standard
> >eclipse.jface
> >code and eclipse.ui patterns. Each fragment invokes an
> >ScmCommand object (b);
> >this avoids duplicating Scm functionality across multiple
> >handler fragments,
> >and should also facilitate adding some kind of scripting
> >capability in future.
> >
> >The ScmCommand objects (b) call model-level APIs and helper
> >objects (c), and/or
> >directly invoke stellation.repos functionality (d). This is
> >still a fuzzy
> >design area: the intent is to have "fine-grained-image" APIs that make it
> >easier for Eclipse code to manipulate branch images and their components,
> >but it may turn out that invoking stellation.repos code directly is the
> >simplest/cleanest solution. I also expect the scm.model code to use the
> >just-revised stellation.workspace.Project, but the rest of the
> >stellation.workspace code will probably be used only by the command-line
> >client.
> >
> >The command-line client (e) will continue to use
> >stellation.repos code (d).
> >In fact, since stellation.workspace essentially *is* the command-line
> >client, we may want to move Project into stellation.repos, or otherwise
> >refactor so that the Eclipse Stellation client avoids any direct use of
> >stellation.workspace code. The dividing line between (c) and (d)
> >is pretty fuzzy at present; (c) may end up containing only
> >Eclipse-specific functionality code (e.g. the current resource
> >change tracking
> >mechanism), with all Stellation-specific functionality in one of the
> >stellation.repos
> >packages, and invoked directly by the Eclipse client code as needed.
> >
> >The end goal is to have a single implementation of the core
> >functionality which
> >is equally usable by both GUI clients and command-line clients.
> >This should
> >also support a standalone SWT-based client reasonably well.
> >(Note, however,
> >that a standalone client won't be able to use Eclipse resource
> >management.
> >Thus, you'll either have to use the stellation.workspace code for local
> >file system
> >management, or roll your own code. It might be easier to use a really
> >stripped-down
> >Eclipse app (e.g. eclipse.core.XXX, SWT, but not much else), as Mark has
> >discussed
> >earlier as a possible way of reimplementing the Svc command-line client.)
> >
> >My coffee still hasn't kicked in quite yet, but I'm sure Mark or
> >Dave will
> >comment if anything I've written is too far off track.....
> >
> >
> >>I am very interested in the core scm API. Once I get a stable version of
> >>Stellation working with Firebird, I will build a standalone SWT-based
> >>Stellation client.
> >
> >Once I have the UI client working again, I'd love to hash out
> >the core scm API
> >with you, Mark, Dave and the other interested parties --
> >
> >Regards,
> >Jim
> >
As I understand your medium to longer term deployment goals, you are looking
at an architecture somewhat like this.
Stellation client
\
\
\
Stellation Server -----------------\ Stellation Server
/ \ \ /
/ \ \ /
Workspace Manager Stellation Repository Hierarchical Stellation
Server
| |
| Hierarchical SS |
| \ |
| \ |
RDBMS Hierarchical Stellation
Server
.
.
.
Master Stellation Server
In this picture, a Stellation client could be any of a command line utility,
a standalone GUI app, a IDE plugin such as for Eclipse, etc.
The Stellation Server contains the core SCM logic and provides access to the
core objects such as Artifacts.
The Workspace manager is concerned with managing the rendering of projects
into a user's workspace. It has two parts to it, a logical workspace manager
that understands workspace concepts and some number of physical workspace
managers, each of which understand how to talk to the physical
representation of a workspace, whether that be Eclipse IFile objects etc.,
Native file systems via standard Java I/O or any other special purpose
arrangement that someone might need.
The Stellation repository component understands how to talk to repository
storage in an abstract manner and can call on RDBMS proxies to provide
database specific smarts.
A hierarchical Stellation server serves as a collection point for local
servers and can also directly function as a Stellation Server with a local
client base.
All components should be accessed via a Java interface only. You may wish to
give some consideration to a standardized communication path between all
components so that they can function in either local or distributed manner.
Just a thought! I have used arcgitectures like this several times in the
past and they have been very successful.
Regards
Jonathan Gossage
Personal Email
jgossage@xxxxxxxx
Business Email
jonathan@xxxxxxxxxxxxxx
