RE: [alf-dev] SCM Vocabulary - Workspaces Problem

["Richard Title" <rtitle@xxxxxxxxxxx>]

My view is somewhere in between what Tim said and what Mark said. :-)

I think it's a useful breakdown of SCM functionality if we define it as 2
services: A "SCM service" and a "Workspace service". The "SCM Service" would
typically be implemented by wrapping the SCM server, and would typically
live on the machine where the SCM repository lives. The "Workspace Service"
would typically be implemented by wrapping the SCM client, and would live on
the machine where the workspaces (and SCM clients) live.

A GET would be implemented by sending a Workspace object to the Workspace
Service. 

Workspace objects might be the output of other operations. E.g., if the SCM
service starts a service flow by saying "hey, a Promote operation just
happened", it might output a set of Workspace objects which are affected
(i.e. need update).

Where I agree with Mark is that I see the *implementation* of both the SCM
Service and the Workspace Service as being the domain of the SCM vendors. I
see ALF as providing the *vocabulary* for both services, with the SCM
vendors actually implementing them. Most likely, in the initial cut, vendor
X's Workspace Service would only be able to deal with Workspace objects
emanating from vendor X's SCM Service. (Because the actual implementation of
a GET operation would involve private communication with its matching SCM
server, on a channel through which the files actually flow). Down the road,
if we do a good job standardizing and agree on various details, we might
achieve inter-operability of Workspace Services and SCM Services across
vendors.

Make sense?

I look forward to discussing this more in 1/2 hour. :-)

Richard Title
AccuRev