Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [platform-vcm-dev] The WVCM API

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

   Our position on a general API for VCM is that we don't want to be
   the ones inventing or imposing an API because we know from
   experience that we shouldn't be in that business. It's up to the
   repository vendors to prove to us that there is buy in for such an
   API. Instead, if there was a reference implementation and an
   Eclipse plugin showing that (a) the API can be implemented, and (b)
   there is interest from other repository vendors to implement the
   API, we could then start investigating how to integrate the API
   into the Eclipse VCM deliverable.

This is a classic chicken/egg issue in the area of API/protocol/service
standardization.  A client writer doesn't want to implement the
client-side code until there are servers that implement it, and
a server writer will not implement it until there are a sufficient
number of clients that use it.

The way we have tried to break this deadlock for a standard CM
interface was to bring together a large number of server vendors, and
defined a mutually acceptable API: this is the WVCM interface defined
by JSR-147.  This largely solves the problem encountered by VCM-1.0, where
the client (Eclipse) made up an API, only to be told by the server
vendors that this API could not effectively drive their server.

But until an important client (e.g. Eclipse) implements this
interface, it is unlikely that a large number of vendors will do so,
since they each already have an optimized interface to their server
used by their proprietary clients.

So I agree with Jean-Michel that until a strong demand for a standard
CM interface is identified, it is best for the Eclipse Team team to
work on improving the integration mechanisms that allow CM providers
to optimally expose their full range of features in the Eclipse shell.
But if such a strong demand is identified, to make it happen, Eclipse
would have to take responsibility for implementing an Eclipse plug-in and
standard implementation of the JSR-147 API, since this is not
something one is likely to get from elsewhere (e.g. a server vendor).

Cheers,
Geoff


Back to the top