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

[Keisuke Fukui]

Attached are the diagrams for the scenario I wrote in below.
Thanks Sachiko for drafting this.

  -Keisuke


Keisuke Fukui wrote:
> Although I haven't thought well about this, attached is the additional
> comments from Steve.
> 
> Considering the url has flexibility to accommodate various protocols
> and indeed concise method to specify the location to the contents,
> here is an hypothetical sequence for the content retrieval:
> 
> 1. The repository should expose a list of protocols supported,
> 2. then the client chooses a preferred one from the list and specify it
>    as a parameter in GetContents,
> 3. then the Repository returns a url that fits to the specified protocol.
> 4. the client should resolve the reference (i.e. get actual contents) from
>    the url.
> 
> We don't need to be bothered how we can translate the arguments parameters
> to GetContents, rather we say returned url is opaque except for protocol
> portion. The url may vary depending on the protocol the client specify.
> We can include Soap_with_Attachment in the list of supported protocols,
> for example:
> 
> supported_protocols = {
>  SwA,
>  file,
>  http,
>  https,
>  ftp,
>  ...
> }
> 
> Then the repository can return the contents as a response message for the
> GetContents instead of url.
> 
> We can do the similar for other interface such as Register/Create. Thus,
> we can formalize the interface and still accommodate the various protocols
> that may be provided by the repository implementation. Does this make 
> sense?
> Or is there better way to specify the interfaces?
> 
>  -Keisuke
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: transport.ppt
Type: application/octet-stream
Size: 34816 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/acs-wg/attachments/20050707/8b2ea64b/attachment.obj