I sense some confusion... Robin Redeker wrote: > On Tue, Aug 28, 2007 at 09:21:43PM +0100, Richard Dobson wrote: >> Peter Saint-Andre wrote: > [.snip.] >>> 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?
It's unclear exactly what you mean. You want a Jingle method as one option in stream initiation, like this? <iq type='set' id='offer1' to='[EMAIL PROTECTED]/resource'> <si xmlns='http://jabber.org/protocol/si' id='a0' mime-type='text/plain' profile='http://jabber.org/protocol/si/profile/file-transfer'> <file xmlns='http://jabber.org/protocol/si/profile/file-transfer' name='test.txt' size='1022'/> <feature xmlns='http://jabber.org/protocol/feature-neg'> <x xmlns='jabber:x:data' type='form'> <field var='stream-method' type='list-single'> <option> <value>urn:xmpp:jingle</value> </option> </field> </x> </feature> </si> </iq> And then you do a Jingle negotiation to figure out how to proceed? > I generally thought that reimplementing all that with jingle is a bad > idea. And I as client/library author surely don't like the idea of > duplicating code or functinality. > > I agree completly with you. See earlier list discussion. We had rough consensus that in the long term client developers didn't want both SI and Jingle as negotiation mechanisms -- that it would be easier to have just one approach. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
