On Apr 05, Ian Foster loaded a tape reading:
Steve's note raises a key point for me: do we really want to force the user (as Savas seems to be advocating) to keep track of jobs running at a remote site?
I'd rather send a request "kill all my jobs" or "kill all my jobs that have run for more than a day" to the factory than carefully keep track of all jobs that I have active, and how long they have been running, so that I can send the big document (or stream) discussed below.
Ian.
Isn't that a red herring though? We're talking about services here, and not user interfaces. Surely some user application or client-side configuration must keep track of which remote sites need cleanup? A user isn't going to broadcast to all sites/services "please kill anything I might have left there". That's what expiration times are for. :-) [sorry, couldn't resist] I agree that there are an unbounded number of interesting and compact expressions selection criteria one might use. I think this alone is justification for something more than enumerated resource IDs. Should this go in application-specific document payload? In the WS-A "To:" field or some other header? Some combination of both? Unfortunately, that last option usually seems to be the right one in these situations. But all of this seems to be going in circles... the underlying questions we need answered when building and operating the infrastructure are: which messages are applicable to this resource, and where do I send them? Are we somehow addressing this while we argue about whether the open parenthesis goes before or behind the message target, and I just cannot see it? karl -- Karl Czajkowski karlcz@univa.com