RE: [platform-vcm-dev] The WVCM API

["Clemm, Geoff" <gclemm@xxxxxxxxxxxx>]

   From: Jean-Michel Lemieux [mailto:Jean-Michel_Lemieux@xxxxxxxxxx]

   We may be able to help out.

Great!

   This doesn't represent a commitment for including the WVCM 
   in the next release of Eclipse, but instead we would like to evaluate it.

Understood.

   To get started, I have a few questions. 

   1. Our experience has shown that methods that can be long running
   (e.g. the doXXX methods) must provide the implementer the ability
   to report progress and allow the caller to cancel. Is there a
   reason for not including this in the API?

I agree that a good provider will want this functionality,
but we didn't come to any consensus as to the standard form form for
the progress indication, so we left that up to a particular provider
(i.e. progress indication will be a provider specific function).

But if you have some suggestion for a standard form for adding progress
indication to the API, we certainly could add it the API.

   2. The API is very rich mainly because it has to supports
   implementations that are non-versioning, support basic versioning,
   or advanced versioning. That is good because we want to support a
   wide range of implementations. However for us to motivate people to
   implement this API it shouldn't be too complicated. Ideally it
   should be fairly obvious what classes/methods must be implemented
   based on the desired support they want to provide. It currently
   seems hard to understand this.

Just thinking out loud, one way to approach this problem might be to
provide a few "stub-providers", where a particular stub-provider stubs
out a particular clump of the advanced functionality.  A particular
provider can then just make their implementation inherit from the
appropriate stub-provider.

(Note: If Java supported multiple implementation inheritance, we could
imagine defining a set of "feature-stubs", where a provider would then
do just have their implementation inherit the feature-stubs of all the
features they don't want to implement.  But Java doesn't, so we can't :-).

   Comments: 

   1. Code example in the Resource class seems wrong: 

   Resource myResource =
myProvider.resource("/my/resource/loc").doReadProperties(wantComment); 
   => should read 
   Resource myResource =
myProvider.location("/my/resource/loc").resource().doReadProperties(wantComm
ent); 

Thanks for noticing that.  Will fix.

   2. A small nitpick thanks to Eclipse warnings: 
   VersionHistory has an unused import java.io.OutputStream, 
   ProviderFactory has an unused import java.lang.refrelct.Constructor, 
   Provider has an unused import java.io.OutputStream 

I'll get rid of those.

Cheers,
Geoff

   "Clemm, Geoff" <gclemm@xxxxxxxxxxxx> 

   The only thing holding up the RI and TCK is getting someone to volunteer
to
   do the work (:-).

   So there are two chunks of work that could reasonably be done by Eclipse
to
   "kickstart" the WVCM adoption process (i.e. to motivate vendors to
implement
   the API):

   - implement an Eclipse Team Provider Plug-in based on the WVCM API
   - implement the WVCM API on some freely available CM system (e.g. CVS). 

   The second chunk of work could then serve as a reasonable RI.
   And if some automated tests have been developed for the second chunk of
   work, that could serve as the basis for the TCK.