On 06/10/2008 3:47 PM, Marcus Lundblad wrote: > tis 2008-06-10 klockan 11:38 -0600 skrev Peter Saint-Andre: >> On 06/10/2008 11:43 AM, Marcus Lundblad wrote: >>> I was just looking a bit at XEP-0047 (in-band bytestreams). >>> >>> In section 6 it says: >>> >>> Example 6. Acknowledging data using iq >>> >>> <iq from='[EMAIL PROTECTED]/balcony' to='[EMAIL PROTECTED]/orchard' >>> type='result' id='ibb1'/> >>> The sender need not wait for these acknowledgements before sending >>> further stanzas. However, it is RECOMMENDED that the sender does wait in >>> order to minimize possible rate-limiting penalties. >>> >>> Further the XEP states that if the server supports Advanced message >>> processing, data should be sent using <message/> stanzas, rather than >>> <iq/> >>> >>> However, when sending <message/> stanzas, is it possible to get an >>> acknowlegment to know when to send the next data chunk without placing >>> to much load on the server? >> You could use XEP-0184 for that, but if you really want acks then IMHO >> it's best to use IQs. > > I suppose it could also be possible to use a callback set to fire off by > a timer in the case <message/> stanzas, to prevent it from flooding the > server. That was my main thoughts, to avoid penalty from the server. > > I have some plans to implement IBB support in libpurple (Pidgin), mostly > as a fallback solution for file transfers when socks5 fails (and later, > maybe even after trying to negotiate a Jingle file transfer).
Yes, the idea behind XEP-0234 is that IBB will be the file transfer method of last resort, but that it will always work (for some value of "always"). > What would be the advantage of using <message/> stanzas? (since it > recommends using them when AMP is available...) Given that AMP is not widely avaiable, I'm not sure how far you'll go with that. But AMP would give you more fine-grained control, such as being able to time out the messages, not deliver them if the user goes offline, etc. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
