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.

Richard

Reply via email to