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
