[Fwd: Re: [cddlm] In preparation for the CDDLM/ACS joint session at GGF14 (re-send)]
FYI,
-------- Original Message --------
Subject: Re: [cddlm] In preparation for the CDDLM/ACS joint session at GGF14 (re-send)
Date: Mon, 18 Jul 2005 13:17:18 +0100
From: Steve Loughran
Steve,
# Let me re-send this since I forget the attachment:-)
Thanks for your update on this.
Considering your comments below, we discussed a WS interface utilizing the uri identification as you proposed. Please take a look at the attachment to this e-mail. This depicts how the ACS Repository Interface "GetContents()" can work with multiple protocols. It is very similar with the AddFile() as it returns an uri. In our interface, Register() that pushes files into the repository returns EPR to the entry, then the GetContents() with protocol and keys to the subpart of the archive entry selects what and how the files can be retrieved from the repository. It will allow the http to be used among the other protocols supported by the implementation of the repository.
Do you think this work for your use case?
-Keisuke
slide1. Yes, this should work. I like the listing of supported protocols, it eliminates much uncertainty. slid2: the use case should show that the http request is being made by a separate application (not the client), which GETs the URL that is extracted from the GetContents response message and then handed to the application. This emphasises that an application at a different location (and with no cookie history, a different IP address,...) will be doing the retrieval. slide3: The contents of the fetch would include a message which contains an identifier/uri to the actual attachment. Otherwise the app is assuming that only one attachment comes in a message, which is not always the case. MTOM is the future of soap attachments, even if support today is patchy-to-nonexistent. Its operation should look similar, except that the data will appear by the time it comes through the soap stack to be an inline base64 element of very large size (and presumably different copy/clone semantics or the implementation will leak files the way axis1.x does) I'd recommend a response message that can take either a uri or inline data, so the same request/response can work for the different types. 4. Caching/performance. If the URL-fetching app is written with the assumption that the repository is some distance away, or intermittently unreachable, it will want to download the resource and cache it. So an HTTP HEAD request may be needed, or a GET with a lastModifiedSince (or better yet, an etag). -steve
participants (1)
-
Keisuke Fukui