[OGSA-D-WG] ByteIO and transport protocols

[Allen Luniewski]

Dave,

Interesting point.  The idea of putting a "future work" note in the 
architecture document for sessions makes sense.  In fact, if we do that we 
should consider just adding a "Future Work" section and fill it with 1-2 
lines about each open area we feel that we should address.

Here is another thought on the ByteIO question.  Let's think about DMI. If 
you think about what a DMI factory does, it ends up creating a transfer 
object which really embodies a transfer session.  So, why couldn't a 
ByteIO aware data service participate as the Source in a DMI transfer?  If 
it did that, then the extension to ByteIO would be to add a TransferObject 
to the Get operation.  The effect would be for the source to pump out the 
specified data over the transfer protocol that DMI negotiated.  This 
leverages DMI and is a simple extension to the ByteIO specification.  I 
suspect that one would have to add an additional operation to ByteIO to 
allow the client to indicate that the last data has been denoted, thus 
causing the Source to declare "end of file" to the Sink.

Allen Luniewski
IBM Cross Brand Services
IBM Silicon Valley Laboratory
555 Bailey Ave.
San Jose, CA 95141

408-463-2255
408-930-1844 (mobile)




"Dave Berry" <daveb at nesc.ac.uk> 
Sent by: ogsa-d-wg-bounces at ogf.org
05/11/2007 02:12 PM

To
<ogsa-d-wg at ggf.org>
cc

Subject
[OGSA-D-WG] ByteIO and transport protocols






One conversation at OGF20 raised the question of how ByteIO can be used 
with transport protocols other than those that return data in the response 
message.  The ByteIO spec deliberately leaves this as an extensibility 
option without specifying how it should be done.
 
It seems to me that it would be too expensive to negotiate a protocol and 
appropriate mechanism for each request in a multi-request activity.  A 
more practical solution would be to establish some sort of session and 
then have the ByteIO operations control the transfer across that session.
 
I wonder whether we should mention this possibility in the architecture 
document?  We have deliberately declared session management to be out of 
scope and I am not suggesting that we go into details, but we could note 
this as an area for future work.
 
Best wishes,
 
Dave Berry
Research Manager, National e-Science Centre 
15 South College Street, Edinburgh, EH8 9AA
Tel: +44 131 651 4039
  --
  ogsa-d-wg mailing list
  ogsa-d-wg at ogf.org
  http://www.ogf.org/mailman/listinfo/ogsa-d-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-d-wg/attachments/20070511/cc2eb797/attachment.htm