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 ;) -- Fabio Forno, Bluendo srl http://www.bluendo.com jabber id: [email protected]
