RE: Philosophical: Batch processing

I wouldn't really call this "batch processing", but in case the
response to a request (such as MERGE) implies a series of actions
that need to be done by a client (such as resolving the merge
conflicts), it would be friendly for a client to guide the user
wrt what actions still need to be performed.  In the case of the
MERGE method, the information about what actions still need to
be performed is maintained on the server (in the DAV:merge-set and
DAV:auto-merge-set of the VCRs in a workspace), so a client can
always retrieve this information from the server (e.g. by a
Depth:infinity PROPFIND on the workspace for the DAV:merge-set
and DAV:auto-merge-set properties).

Cheers,
Geoff 

-----Original Message-----
From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]
Sent: Wednesday, February 13, 2002 7:52 AM
To: Ietf-Dav-Versioning (E-mail)
Subject: Philosophical: Batch processing


Hi,

I have a philosophical question dealing with batch processing in DeltaV. Is
it right to suppose that batch processing functionality must be provided by
the client? 
Well lets take an example. Merging a workspace (containing a complete
codeline) into another workspace may be a huge task to fullfill. Typically
such tasks/jobs would be startet in batch mode. So a client could or would
have to provide a scheduler that is the tool for scheduling batch jobs.
Problem is that the server would reply instantly when the request is
completely performed. The client would have to store the replies to provide
them as soon as they are requested.
This is definitly a way to it. But what about this MERGE above? Typically
the reply contains failed merges that have to be handled somehow. Performing
such a MERGE would raise failures that different developers have to handle.
So a central batch processing support would be a nice thing. Anyway you
still could have an administrator client that provides batch processing and
messaging of failures to the developer responsible.

Does anyone has experiences with this topic? Oppinons?

Regards,
Daniel

Received on Wednesday, 13 February 2002 08:51:37 UTC