On Sat, May 30, 2009 at 3:17 AM, Peter Saint-Andre <stpe...@stpeter.im> wrote: > Yes, I agree. Is XEP-0144 good enough, or do we need to (1) improve it > or (2) define yet another approach to solving the problem?
Basically improvements, trying to solve the few situations leading to an undetermined behavior. For example in "iq semantics" it is written: "If the receiving entity successfully processes the suggested action(s) (which may include ignoring certain suggestions), the receiving entity MUST return an empty IQ result to the sending entity". This approach presents some issues: - if the sender of the items is a different entity from the one which will process subscriptions it is impossible to know which modifications have been accepted or rejected - even if the two entities are the same it is not possible to know why some subscriptions haven't been processed. For example if we don't receive a subscribe we can't distinguish an explicit reject from client side issues (network problems, client crash, users forgetting to take actions before ending their session) and this is bad, since we don't know whether to resend them or not Imho an <iq/>, with the accepted modifications, sent back to the sender after the user has processed the additions would solve the problem (we just need a session-id for linking the this notification to the triggering first request). bye -- Fabio Forno, Ph.D. Bluendo srl http://www.bluendo.com jabber id: f...@jabber.bluendo.com
