[BYTEIO-WG] Notes from the OGSA ByteIO session at OGF19

[Michel Drescher]

Hi Andre,

Andre Merzky wrote:
> Quoting [Michel Drescher] (Feb 10 2007):
>> Hi Andre,
> [...]
>> But even so, this is an *optional* feature, something we cannot rely on. In 
>> HTTP for example, partial data transfer is a MUST, so it is feasible to 
>> define a profile for HTTP as each compliant implementation will offer that 
>> feature.
>>
>> What sense does it make to define a rendering for a feature that is 
>> optional in the underlying transport protocol?
> 
> Yes, I agree, that is a definite problem.
> 
> However, if I am not mistaken, all gridftp implementations
> implement partial file transfer.  Also, gridftp has a number
> of advantages over HTTP IMHO: comes with globus and other
> middleware, and is nicely (ahem) integrated into the
> security infrastructure.

:-)
ByteIO itself is agnostic to security (TBD or orthogonal), so this must not
be taken into consideration.

However, ByteIO is considerably different in its use cases and requirements
from GridFTP. Hence a different architecture. GridFTP is designed to
accomplish file *movement* while ByteIO is designed to solve file (well,
data) *access*. As a consequence, GridFTP requests for small amounts of
data are simply way too slow when compared to simple HTTP or parallel HTTP.

I don't advocate against a GridFTP rendering - I just do not want to put
the "burden" (in terms of time effort) on the ByteIO group itself because
of the above mentioned reason(s). The group would be glad to see a
rendering contributed from external sources, I suppose.


Cheers,
Michel


-- 
Michel <dot> Drescher <at> uk <dot> fujitsu <dot> com
Fujitsu Laboratories of Europe
+44 20 8606 4834

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : http://www.ogf.org/pipermail/byteio-wg/attachments/20070215/a6dfef99/attachment.pgp