RE: Questions/clarification on MKACTIVITY method

This would by no means be wrong (and in one draft of the protocol
was the *only* way that MKACTIVITY worked).  But other members of
the design team felt that it was simpler/better to have this be
under client control, i.e. a client can allocate a GUID for the activity
name if it so desired, but the server's job is just to instantiate
the activity with the name specified by the client.

Personally, I can live with either way, but to minimize protocol
complexity, I'd probably prefer us to support one way or the other
way, but not both (i.e. not add a flag to MKACTIVITY for this).

Cheers,
Geoff

-----Original Message-----
From: Steve K Speicher [mailto:sspeiche@us.ibm.com]

One final comment *hopefully* ;-)

>In general, there are multiple modules/servers that handle different
>subtrees at a web site, and often the DAV module will not handle
>"/", but rather some subtree such as "/dav".  Assuming that a request
>to "*" gets handled by the module that handles "/", the
>MKACTIVITY request will not be understood.  In addition, if there
>are multiple DAV modules handling different parts of the namespace,
>each with its own activity store, it is important that the
>activity gets created in the right activity collection (not something
>that can be inferred from "MKACTIVITY *".

I guess my example was too simple (and wrong perhaps).  In order for a
client to find out what activity-collection to use it must first issue an
OPTIONS request with a given URL, say http://repo.dav/dav/ and gets the
property DAV:activity-collections-set.  Why couldn't I form a request,
like:
   MKACTIVITY /dav/* HTTP/1.1

And get the response (implicity do an OPTIONS request to get
DAV:activity-collections-set):
   HTTP/1.1 201 Created
   Location: http://repo.dav/dav/act/123
?
Or am I completely wrong in thinking it would be a valid operation of a
activity-enabled server to assign an activity identifier using MKACTIVITY?
Most bug-tracking servers have an option/configuration to automatically
assign a number but I'm trying to determine if this is outside the scope of
this protocol.

Thanks again,
Steve

Received on Monday, 12 March 2001 17:31:52 UTC