[Standards] file transfer
Richard Dobson
richard at dobson-i.net
Tue Aug 28 15:21:43 CDT 2007
Peter Saint-Andre wrote:
> Richard Dobson wrote:
>>> No, it would work the other way around -- it enables you to re-use your
>>> existing SOCK5 and IBB code, but for the negotiation you'd use Jingle
>>> instead of SI.
>> Ah I see, I thought so, I was suggesting doing things the other way
>> around which would be far more backwards compatible as you wouldnt need
>> to implement two separate ways of initiating file transfers which allows
>> you to reuse not just the SOCKS5 and IBB code but also the SI and file
>> transfer initiation code and you are just adding an extra stream-method
>> which makes things much simpler, certainly for me it would make
>> implementing it 100x simpler as my SI/file transfer code is all
>> abstracted out and all I would need to do was implement a jingle
>> bytestream stream-method, not redo all the file transfer discovery,
>> offering, acceptance etc etc which makes things very much more complicated.
>
> I understand. But SI and Jingle essentially perform the same functions,
> since they both enable negotiation.
Yes but jingle also provides access to ICE and pseudo-tcp so it would be
helpful rather than have the entire file transfer negotiation using just
jingle if it was separated in two so that all the jingle side is doing
is negotiating a generic bytestream that can be then reused by things
like SI, to me this seems like a sensible compromise as there is no real
benefit that I can see of doing the whole thing in jingle as its just
duplicating effort, whereas creating a new bytestream method is
complimentory, anyone else think its a good idea?
Richard
More information about the Standards
mailing list