RE: [alf-dev] ALF SCM Vocabulary compared toWebDAV VersioningExtensions

["Richard Title" <rtitle@xxxxxxxxxxx>]

Re: "failed projects": Doesn't Subversion use WebDAV/Delta-V as its
client/server protocol? ( http://subversion.tigris.org/webdav-usage.html ).
Some might argue with this characterization of WebDAV and JSR-147.

But fundamentally, I agree with you. You're making essentially the same
point I and Tim were making. In the context of ALF, we are only concerned
with the higher-level requests that a non-SCM tool might make of an SCM
system (e.g., update-workspace, checkin new revisions, etc). If we get
bogged down in the internal protocols of an SCM system, or in supporting the
functions of an SCM systems (e.g. moving files around, or workspace
management) then we lose. I was going to make that point right after last
week's meeting: I don't think ALF should be providing workspace-management
services or distributed filesystem services for SCM systems, any more than
it should be providing record/playback services to testing tools. ALF really
needs to focus on the inter-tool interfaces. I was going to write a message
to that effect, but got bogged down in other work instead...

Cheers,

Richard Title

-----Original Message-----
From: alf-dev-bounces@xxxxxxxxxxx [mailto:alf-dev-bounces@xxxxxxxxxxx] On
Behalf Of Mark Phippard
Sent: Wednesday, May 03, 2006 10:39 AM
To: ALF Developer Mailing List
Subject: RE: [alf-dev] ALF SCM Vocabulary compared toWebDAV
VersioningExtensions

alf-dev-bounces@xxxxxxxxxxx wrote on 05/03/2006 10:21:21 AM:

> One issue is that WebDAV is not a SOAP based web service and is not 
> (probably cannot be) described by WSDL.  Thus it isn't directly usable 
from 
> BPEL. (should double check to be sure I'm not missing something)
> 
> I have a general impression that the versioning part of WebDAV has had 
mixed
> acceptence and spotty implementation but I'll leave it to others to 
expand on that.
> 
> Both WebDAV and JSR are client oriented and have the same "workspace" 
issue 
> that we need to address to avoid streaming files through the BPEL 
engine.
> 
> Thus I believe neither is directly applicable although clearly they are 
both
> good sources to leverage and validate against.  It would be a good 
exercise 
> to reference the equivalent concepts and operarations of these two 
sources 
> in our document.

I cannot help but think we are getting off the tracks here. 

First off, the WebDAV DeltaV Extensions and the referenced JSR 147 are 
both essentially failed projects even though they included participation 
by a lot of the top vendors.  If we keep expanding the scope of what we 
are doing we are going to head in the same direction.  It seems like the 
SCM Vocabulary discussion has started to head down the road of talking 
about how an SCM Client would talk to an SCM Server.  I was not at the 
last meeting so maybe this has been clarified already.  Anyway, that seems 
like it is not the intent of what we were doing with ALF, at least as I 
perceived it.

In terms of ALF and SCM it seems like we should be thinking about:

1)  What kinds of "event notifications" should an SCM system send to the 
ALF Event Manager.  For example, "a check-in has just happened by user X 
of files A B and C referencing issue ID 123"  Or something like that.

2)  What kinds of basic services should an SCM provider expose so that ALF 
Service Flows and other tools can work with the system.  This can easily 
expand to becoming a full-blown SCM.  I think we should try to keep it 
simple and limit it to the kinds of tools we can envision wanting to 
interact with an SCM system.  I also do not think we should try to attempt 
this workspace management stuff.  If we do, we are likely to fail given 
that these other projects all have.

3)  Finally, is there any room in ALF for prescribing "validation" events? 
 In other words, could an SCM tool send an event to ALF that indicates a 
user was about to do a check-in.  And ALF could then initiate some kind of 
service flow that ultimately said whether or not it was OK?  This seems 
like it could get really complicated to define but it has a lot of room to 
add value.  For example, perhaps we want to validate that the check-in is 
associated with an issue, and that the issue is in a state with the 
necessary approvals to allow the work to be done?  I could also see 
wanting to do style or security checking but that would mean a client 
would have to somehow provide the contents of the local changes and I 
cannot see that being possible.

What this gets back to is something I have brought up previously and that 
is that it seems like we are lacking the necessary "vision statements" 
that describe the intent and limits of the project and its pieces.  It is 
great to have "grand ideas" but if we ever want to ship and be useful it 
seems like we need to be more focused and realistic.  I am all in favor of 
referencing something like WebDAV or JSR-147 in order to "borrow" the 
terminology choices they made.  I would even say that is a good idea to do 
so since those projects had broad industry participation.  But if we start 
heading down the same roads they did in terms of the scope of our project 
it seems like we are destined to fail.

Mark


____________________________________________________________________________
_
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM
Email Security Management Services powered by MessageLabs. 
____________________________________________________________________________
_
_______________________________________________
alf-dev mailing list
alf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/alf-dev