[acs-wg] [Fwd: Re: [cddlm] In preparation for the CDDLM/ACS joint session at GGF14 (re-send)]

[Keisuke Fukui]

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_loughran at hpl.hp.com>
To: Keisuke Fukui <kfukui at labs.fujitsu.com>
CC: 'cddlm-wg at ggf.org' <cddlm-wg at ggf.org>
References: <42B92AB0.3080802 at labs.fujitsu.com> <42B94FBC.70406 at hpl.hp.com> <42BB559D.6020600 at labs.fujitsu.com> <42BBD923.1010509 at hpl.hp.com> <42BC935C.4090501 at labs.fujitsu.com> <42C92E87.6090508 at hpl.hp.com> <42D1D6EF.5010108 at labs.fujitsu.com>

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