-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/17/09 7:39 AM, Fabio Forno wrote: > On Wed, Sep 16, 2009 at 8:51 AM, Ralph Meijer <[email protected]> wrote: > >>> There are several problems in this approach: >>> - messages can be delivered to the wrong resource and be lost at >>> application level >>> - you can flood the offline storage >>> - some events could get delivered when they are too old to have a >>> meaning and never know that they get late, unless you add some more >>> logic to the application >> This might be solved by implementing AMP, but that doesn't seem to be >> very popular yet. > > I haven't any server supporting it (but an external contibution of > ejabberd) ;). Though the lack of implementations is no excuse for not > adopting the correct solution, this fact makes me think about the > reasons... I see some: > - AMP would work only if it were a mandatory technology to implement, > so there is little interest in implementing it first when in most > cases it wouldn't work > - since it is a server to server technology (correct me if I'm wrong, > but the recipient client is not involved) you still require an ack > from the client and using two different mechanisms together for the > same thing is not good > - I prefer end to end solutions, with very little server involvement > (session management is a special case because it involves just one hop > and needs to be processed at session level) > > <iq/>s instead don't have all these problems ;)
Right. But then pubsub service needs to be smart, either by requiring full-JID subscriptions or doing some kind of discovery to determine available resources for the subscribers. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqyRBgACgkQNL8k5A2w/vwh7ACeJCxG6tqNNEBq6E/QEnv045u3 yXcAnRbS1xbU2tqO5c8tnyX6KaucQn7V =SzyJ -----END PGP SIGNATURE-----
