The general consensus seems to be that the SWAP group should
mainly take existing Workflow Management Coalition interfaces
(WfMC) by combining and repackaging parts Interface2 through
Interface4 [3] to be compatible with HTTP. Extending HTTP
to be the substrate for other protocols has become a
religious issue, particularly in the world of protocol
explosion. [4] The decision about supporting the WfMC
interfaces is a hot internal topic of debate. The assessment is
that if the interfaces aren't of "unimpeachable" quality
then there is no serious argument for using them as a starting
point. Needless, this reduces the motivation for many
of the WfMC participants to, well, participate.
It's interesting to note that the makeup of the group is
about as follows: 97% roughly don't want to cede the competitive
edge of doing workflow on the Internet to their competitors,
3% are interested in doing the work to actually come up with
a standard.
Of course there are other problems. The WfMC has set up
an oversight working group to oversee the SWAP working group
to make sure that if SWAP comes up with something interesting,
they can fast-track it through WfMC as a standard too. The
WfMC recognizes the extreme importance of working on the Web,
have an excellent handle on the scope and issues [5]
but they are basically clueless on how to transition their
existing work to be compatible.
The other problem is some of the items that SWAP has
define as out of scope are the key differentiators between
it and other protocols. For instance the Joint Flow (JFlow)
initiative is a working group using the Internet (not HTTP)
to define how to coordinate workflow engines across the
Internet. Similarly, the Internet Printing Protocol
has been in existance for longer than SWAP and they have
a draft of how to control asynchronous jobs using the Internet
and HTTP. The way SWAP was defined, many of the services
are related, but differ in syntax.
I just finished an overview article on SWAP, so I've had
to digest the body of information provided and distill
it in such a way that the current thinking is presentable.
I've thought about putting a "the opinions expressed..."
at the top of the article, but that would be tacky. It's
hard to determine what exactly the best approach is, but
if you never POST anything, you never get feedback.
So, the current issues is, to add methods to HTTP similar
to what WebDAV did, or to encode everything completely in
XML and pass it as a bucket as the XML/EDI folks seem to want
to do. This got me thinking. Distributed authoring and
versioning is what I would describe as a first-class concern
for the WWW. First class concerns should of course be
incorporated into the infrastructure where you don't have
to think about it every time you use it. Other first
class concerns, I would argue, are documented in the
infamous Cobbler's paper [6]. I think Internet scale
notification is one. Another I have to argue is Coordination
support. Metcalfe in his Nerds2.0.1 segment said that
the next killer app will be telepresence. No matter how
corny that sounds, I think it's inevitable, although probably
not going to happen the way he described it. I think of
it as the virtual enterprise model with distributed participants
working towards common goals and cooperating where and when needed.
You don't need a telepresence to assert that you locked a file,
and you don't need one to assert that you are done with a
task you were working on and were ready to publish and send
it to the appropriate people interested.
I have to admit my ignorance on the HTTP-NG working group
other than their desire to replace HTTP completely with
a 'truly' distributed object system and to use XDR for pickling,
but my gut feeling is that first class concerns should be allowed
a small number of HTTP methods. WebDAV got several, but to me, the two most
important are PROPPATCH and PROPFIND (maybe MKCOL?, GETHISTORY?). With those
primitives you can supply the functionality for almost all of the others.
For ISEN it should be PUBLISH, SUBSCRIBE, and NOTIFY, maybe UNSUBSCRIBE,
but I can see doing the last other ways than having it be
a method call. For SWAP I think it should be CREATE, SOMETHING and COMPLETE.
I am not sure what that something should be. I was thinking EXECUTE, but then
you could
just use a RUN method (is there a run method standard? I've seen
lots of implementations). Even so, the terminology is important.
Thinking about SWAP, all the functionality that they group
has been talking about can be implemented using, GET, PUT, POST,
PROPPATCH, PROPFIND, PUBLISH, SUBSCRIBE, NOTIFY, EXECUTE, COMPLETE.
Oh wait, maybe HEAD call also.
Anyways, just brainstorming about tweaking infrastructures.
Greg
[0] http://gbolcer.ics.uci.edu/papers/swap.html
[1] http://home.netscape.com/newsref/pr/newsrelease597.html
[2] http://www.ics.uci.edu/pub/ietf/swap/
[3] http://www.wfmc.org/
[4] http://www.ics.uci.edu/pub/ietf/http/draft-iesg-using-http-00.txt
[5] http://www.aiim.org/wfmc/finalwp.pdf
[6] http://www.intraware.com/ms/mktg/indaa/abs/web_based_abs.html