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@nesc.ac.uk> Sent by: ogsa-d-wg-bounces@ogf.org
05/11/2007 02:12 PM
To
<ogsa-d-wg@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@ogf.org
http://www.ogf.org/mailman/listinfo/ogsa-d-wg