[cddlm] In preparation for the CDDLM/ACS joint session at GGF14 (re-send)

[Steve Loughran]

Keisuke Fukui wrote:
> 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