Re: [platform-vcm-dev] FW: Separating the "VCM-GUI hooks/callbacks" from

[Kevin_McGuire@xxxxxxx]

Hi Geoff,

I actually agree in principal with your post.  There are a few 
clarifications I should make which I hope will address your issues.

Let's ignore the CVS support for a moment, which could be considered a 
seperate project that just happens to be done by the same team.

In that case the VCM has three components:

1.  Extension points and API in Eclipse to provide a strong level of 
integration.  There are actually several parts:

a) A small set of VCM hooks.  These are things like:  maintaining the 
mapping from project to Provider, registering your Team nature, an 
extension point for registering your wizard to form that initial 
association between project and provider, etc. 

b) Desktop hooks.  These aren't VCM specific, but are required for a 
complete VCM story.  Here the VCM team is working with the desktop team to 
understand the requirements and to advance the available support for 2.0. 
Examples are: object contribution extensions to allow a provider's menus 
to show up in JDT and other plugins, provider specific decorators, etc. 
Also related is the logical to physical problem which we are devoting some 
thinking cycles to.

c) Core hooks.  Examples here include validateSave and validateEdit.  The 
latter is actually a core hook which the standard text editor uses.

The VCM team is championing the items in (b) and (c) on behalf of 
repository providers, providing usecases and requirements to the other 
teams.


2. Headless API.  We feel it is important that there exist an API that 
plug-ins can call in order to do some simple repository neutral VCM 
operations.  Since these operations would typically be scripted (e.g. a 
build script), they can't rely on prompting etc. and so must be headless. 
Currently our ITeamProvider API supports this, but perhaps shouldn't (more 
on this later).

3.  Generic UI (as you mentioned), and an API to leverage this.  This is 
currently ITeamProvider again, plus some additional APIs to enable things 
like the synchronization viewer.  The set of reusable UI pieces will 
likely be small but hopefully sufficient to get people up and moving fast.


Specifically wrt your comments:

>> The reason that this is important for an Eclipse user is that if an 
editor/IDE
>> invokes both the VCM-GUI hooks and the TeamProvider interface, then
>> the user will be seeing two incompatible sets of GUI's for the same
>> repository operations 

It is up to the provider to decide how much he wants for free, and how 
much he wants custom.  The menu filtering/etc., is based on a project 
nature, with one and only one provider specific nature for each project. 
Ensuring this single association between project and provider is captured 
in 1(a) above.  Thus you won't get two Gui's for a given project: you will 
get exactly that VCM GUI that you the provider decided on.

>> A repository provider
>> would probably want to look at the TeamProvider API and if it maps
>> reasonably well to their repository, they might be able to re-use part
>> or all of the "generic" VCM-GUI implementation, and just implement
>> themselves the TeamProvider API.  Alternatively, a repository provider
>> might decide to just ignore the TeamProvider interface and just
>> implement the VCM-GUI hooks and callbacks directly (that is for
>> example, what we will be doing for ClearCase).

Yes, I agree 100%.  I think we've achieved this, almost.

The 'almost' is because I think we've tried to double up on #2 (headless) 
and #3 (generic UI) where perhaps we shouldn't have.  The problem becomes, 
if you the provider either doesn't wish to support #2 or feel you can't 
due to semantic incompatibility, then you would like to opt out completely 
from implementing ITeamProvider.  And if you don't want #3 because you 
want a rich provider specific UI, the question becomes why are you forced 
to implement ITeamProvider?

Q:  As a side note, for any provider capable of supporting SCC (which most 
can), I would think you *could* support ITeamProvider API, and I would 
like to understand if this isn't true. 

Given the above, I believe you shouldn't have to implement ITeamProvider 
API.

We likely still need an object like ITeamProvider to describe the 
connection between Eclipse projects, etc., and a provider.  We could 
however move methods such as checkin/checkout/etc. out of ITeamProvider to 
somewhere else, so that its clear you only have to implement those methods 
to allow provider-neutral plugin access, or to get generic UI.

In time then you could decide if the demand for plugins to do 
provider-neutral VCM operations warrants implementing the API (assuming 
you can, modulo my question above).

There is a related question you asked regarding how we can split up the 
various bits into different projects/plugins so you don't get pieces you 
don't need.  This can be solved at a later time once we are all clear on 
the seperation.

Kevin






"Clemm, Geoff" <gclemm@xxxxxxxxxxxx>
Sent by: platform-vcm-dev-admin@xxxxxxxxxxx
12/09/2001 10:27 AM
Please respond to platform-vcm-dev

 
        To:     "Vcm (E-mail)" <platform-vcm-dev@xxxxxxxxxxx>
        cc: 
        Subject:        [platform-vcm-dev] FW: Separating the "VCM-GUI hooks/callbacks" from the 
"TeamProvid er" API

Currently there appear to be 3 related projects taking place in the
VCM project.

1) A set of VCM-GUI hooks and callbacks that allows a rich integration
   between an editor and a team repository provider.  These VCM-GUI
   hooks defines a set of hooks that an editor/IDE must invoke at the
   appropriate times, and a set of callbacks that an editor/IDE must
   implement.  Conversely, a team repository provider must implement
   the hooks, and must invoke the callbacks at the appropriate times.
   An example of a hook that an editor/IDE must invoke (these aren't
   the actual names) is "validateEdit()", when it first modifies a
   buffer associated with a file.  An example of a callback that an
   editor/IDE must implement is "fileHasChanged()", when a team
   repository provider has updated one of the files in the workspace.

2) A CVS VCM provider, that provides a CVS implementation of the
   VCM-GUI hooks and callbacks.

3) An implementation of the VCM-GUI hooks that calls a simple generic
   "TeamProvider" API.  Unlike the VCM-GUI hooks, (which assume that
   GUIs will pop up when many/most of the hooks are called), the
   TeamProvider API is a "headless" API, i.e. no GUI's will pop up.
   The purpose of this implementation is to make it easy to write a
   simple team repository provider, since all the GUI code has been
   written, and the team repository provider only implements the
   TeamProvider interface.  Question: Is the CVS VCM provider based on
   this generic GUI that invokes the TeamProvider interface, or does
   it have its own custom GUI that doesn't go through the TeamProvider
   interface?

I believe it is very important (both for repository vendors, and for
users of Eclipse) that we clearly separate these three projects.  In
particular, the editors and IDEs should only call the VCM-GUI hooks,
and should not directly invoke the TeamProvider interface.  The reason
this is important for repository vendors is that the TeamProvider
interface is incompatible with core functionality of advanced CM
repositories (e.g. it does not support versioned namespaces, it does
not support versioning at the project level, it does not support
change-set based behavior, it does not support sophisticated file area
management, and it does not support server-side merging).  The reason
that this is important for an Eclipse user is that if an editor/IDE
invokes both the VCM-GUI hooks and the TeamProvider interface, then
the user will be seeing two incompatible sets of GUI's for the same
repository operations (i.e. the GUI defined by the editor/IDE for the
TeamProvider interface, and the GUI defined by the repository vendor
for the VCM-GUI hooks).

This separation actually simplifies the job of editor/IDE tool writers ...
they implement just the VCM-GUI hooks and callbacks, and don't
have to even be aware of the TeamProvider API.  A repository provider
would probably want to look at the TeamProvider API and if it maps
reasonably well to their repository, they might be able to re-use part
or all of the "generic" VCM-GUI implementation, and just implement
themselves the TeamProvider API.  Alternatively, a repository provider
might decide to just ignore the TeamProvider interface and just
implement the VCM-GUI hooks and callbacks directly (that is for
example, what we will be doing for ClearCase).

Do folks agree with this characterization of the VCM work?  If so, I
think it is very important to clearly distinguish the VCM-GUI
hook/callback interface from the generic and CVS VCM-GUI hook/callback
implementations, and make it clear to editor/IDE writers that they
MUST implement the VCM-GUI hook/callbacks, and MUST NOT invoke the
TeamProvider API (the TeamProvider API is only for repository
implementors).  One possibility would be to actually separate these
three projects (or make the generic and CVS implementations be
sub-projects of the VCM project).

Cheers,
Geoff Clemm
Chief Engineer, ClearCase Business Unit, Rational Software
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev