-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 5/30/09 3:35 AM, Fabio Forno wrote: > On Sat, May 30, 2009 at 3:17 AM, Peter Saint-Andre <[email protected]> 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).
OK. Feel free to work on the spec. I can give you SVN access. :) 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 iEYEARECAAYFAkoliZoACgkQNL8k5A2w/vz4AACeKd0fz6ICFMYFPE2IFIfmATuU 3EcAnAx6D+Hnw9OU01rjgWj6Q9C/z8Gg =Q0kB -----END PGP SIGNATURE-----
