Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

--
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

Back to the top