Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [alf-dev] ALF SCM Vocabulary compared to WebDAV 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. 
_____________________________________________________________________________


Back to the top