[cddlm] In preparation for the CDDLM/ACS joint session at GGF14
Keisuke Fukui
kfukui at labs.fujitsu.com
Wed Jun 22 18:05:42 CDT 2005
Hi Dejan and et al,
# This is a resend. I forgot the attachement ;-p
Thanks for your offer. Unfortunately, I missed the call.
FYI, we have acs-wg regular call soon today. You can join
acs-wg one if you like. Attached is an info.
We can start with CDDLM changing the order of the topics in the agenda.
-Keisuke
Milojicic, Dejan S wrote:
> Hi,
>
> We can also start this discussion at our last regular CDDLM phone
> conference before GGF, which will start in about half an hour.
>
> Thanks,
>
> Dejan.
>
>
>>-----Original Message-----
>>From: owner-cddlm-wg at ggf.org [mailto:owner-cddlm-wg at ggf.org]
>>On Behalf Of Steve Loughran
>>Sent: Wednesday, June 22, 2005 4:47 AM
>>To: Keisuke Fukui
>>Cc: 'cddlm-wg at ggf.org'
>>Subject: Re: [cddlm] In preparation for the CDDLM/ACS joint
>>session at GGF14
>>
>>Keisuke Fukui wrote:
>>
>>>Folks in the cddlm-wg,
>>>
>>>As you know we will have a joint session at GGF14 between
>>
>>CDDLM and ACS.
>>
>>>This is in preparation for the session from acs-wg.
>>>After the GGF13 inside the acs-wg, we studied and discussed
>>
>>about the
>>
>>>possible interactions between CDDLM and ACS, especially in terms of
>>>"File upload" section and AddFile() in the deployment API document.
>>>Sequence diagrams in the attachment describe our
>>
>>interpretation about
>>
>>>how CDDLM works, and our proposal for the possible
>>
>>interactions in the
>>
>>>case that the ACS co-exists in the system. We believe our proposal
>>>goes along with what the current set of CDDLM specifications define
>>>and doesn't require change in the original definitions.
>>>
>>>We are looking forward to discuss about this at the joint
>>
>>session for
>>
>>>CDDLM/ACS at GGF14. It is very much appreciated if we get responses
>>>before the joint session at GGF14 in case that important
>>
>>overlook in
>>
>>>our understanding is found. Please feel free to make
>>
>>comments or questions.
>>
>>>FYI,
>>>At GGF14 joint session, we'd like to start our discussion with this
>>>diagram and if we don't find critical issues, we may go down to the
>>>detail of the interface and/or advanced interaction. We'd
>>
>>also like to
>>
>>>hear requirements on ACS in terms of the event notification and
>>>asynchronous invocation of the interfaces, if the time permitting.
>>>
>>>Thanks in advance for you efforts on this!
>>>
>>>Best Regards,
>>>Keisuke Fukui
>>>ACS-WG
>>>
>>
>>thank you, I will comment briefly.
>>
>>-The File upload stuff was very much written to be a
>>transient/interim solution in the absence of a real
>>repository, which is why it is so minimal and barely
>>functional. I didnt want to be dependent upon anything not
>>yet designed, but didn't want to do a repository myself
>>
>>-the current revision allows the sender to declare the URL
>>schema to use. That could be file: for a shared filesystem
>>and http: or https for HTTP access. It could also be fancy
>>custom stuff; there is some java project whose name escapes
>>me that provides a multicast URL resolution system, the file
>>could be stored across multiple machines without ever having
>>to give them a hostname, which is very good for fault-tolerance.
>>
>>-There is also support for adding metadata to a request, but
>>nothing to do searches, retrieval, or even introspection on
>>what stuff is supported. I've left that for implementations.
>>
>>-There is the perennial problem of how to get files up over
>>SOAP. SwA is only available in java distrubutions, and then
>>not consistently, DIME is in .NET WSE and Axis 1,x, but even
>>more unpopular. As for MTOM, well, who implements that yet?
>>
>>As a workaround I've put in stuff for having the endpoint
>>actually retrieve the files themselves, but this is a bit
>>unsatisfactory, because it requires the files to be broadly
>>visible on the 'net, and introduces race conditions.
>>Otherwise, data goes inline in base-64 encoded form,
>>unless/until MTOM lets you pretend that the file attached to
>>the message is really inline base 64.
>>
>>
>>here are two example mesages and responses from the
>>XSD-validation tests
>>
>>
>>
>> <api:addFileRequest>
>> <api:name>urn://45</api:name>
>> <api:mimetype>application/x-pdf</api:mimetype>
>> <api:schema>file</api:schema>
>> <api:uri>http://example.org/files/source.pdf</api:uri>
>> </api:addFileRequest>
>> </t:test>
>>
>> <api:addFileResponse>
>> <item>file://nas1/temp/source.pdf</item>
>> <item>file://nas2/4fgdbb.tmp</item>
>> </api:addFileResponse>
>>
>>
>>
>> <api:addFileRequest>
>> <api:name>urn://46</api:name>
>> <api:mimetype>application/x-ssh-key</api:mimetype>
>> <api:schema>http</api:schema>
>> <api:data>
>> AAAAB3NzaC1yc2EAAAABIwAAAIEAwVmUkPzXdWEyJZ8nCR8GvdrDtO00RI4Z
>> Bg3Gyviuz5IrWj2C6b2BdcKn+S/swDV1fiEFY4+ewYHUfmg+UKm2T8Lfksjn
>> Hinks0GoVvkwy3bF48U5yVk1akAzR5YbSLJa6Naj8XS9681xVzWpbjxrV3KR
>> QNWvEqI0MqRE34MzT4M=
>> </api:data>
>> <api:metadata>
>> <x:expires date="2005-07-18"
>>xmlns:x="http://example.org/expiry" />
>> </api:metadata>
>> </api:addFileRequest>
>> <api:addFileResponse>
>> <item>http://server/job5/files/1</item>
>> </api:addFileResponse>
>>
>>
>>On a related note, I see that Fujitsu are listed as one of
>>the interested parties in JSR 277, the java
>>modules/repository proposal. Are you involved in that?
>>
>>-steve
>>
>>
-------------- next part --------------
An embedded message was scrubbed...
From: Keisuke Fukui <kfukui at labs.fujitsu.com>
Subject: [acs-wg] Agenda for the Call on Jun 22 Mon 20:00 EDT/Jun 23 Tue 9:00 JST
Date: Wed, 22 Jun 2005 18:21:47 +0900
Size: 6638
Url: http://www.ogf.org/pipermail/cddlm-wg/attachments/20050623/86a32b8d/attachment.mht
More information about the cddlm-wg
mailing list