[Bug 23963] Support for presence optimisations

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=23963

--- Comment #13 from Senko Rasic <senko at senko.net> 2011-02-25 02:50:44 PST ---
C/P from IRC discussion:

<wjt> re queueing stanzas, i've realised there's a third case:
<wjt> for incoming IMs, we need to deliver them immediately, and flush the
queue; for PEP notifications, we can delay them, and preserve ordering; for
incoming disco queries (for example) we want to reply immediately, but not
flush the queue
<wjt> a first approximation would make disco queries flush the queue. but we
don't need to preserve ordering of them versus anything else. ditto xmpp ping:
we should reply sooner rather than later, or risk disconnection, but we
shouldn't need in a perfect world to flush the queue

<ptlo> wjt, wrt each handler specifying whether it minds the delaying, i think
it could get quite hairy, not only for the examples you gave; one other example
is what if my handler says it's unimportant, but i only optionally handle the
stanza, and the next handler that's going to be called (if i don't handle it)
actually thinks its important; also, you would need to pepper both wocky and
gabble with knowledge of what can and cannot be delayed, and i'm not 100% sure
that's not dependant on the use case so that would basically encode powersaving
policy into wocky and gabble (parts in each)
<ptlo> and after some time i fear it might become difficult to reason what
exactly happens on which combination of important and unimportant handlers

<wjt> i don't think it would
<wjt> each handler would register whether it likes stanzas immediately,
immediately and out of order, or not immediately
<wjt> for each stanza, we scan all available handlers
<wjt> if any of them fall into class a, flush the queue
<wjt> if some but not all fall into class b, flush
<wjt> if all fall into b, don't flush
<wjt> if all are in c, queue
<wjt> i guess that's not exactly simple :)
<wjt> but i think the information on how important dispatching a stanza is
lives with its handler

So I think we have two possible ways of doing this:
  * preserving the stanza ordering and having Wocky just ask the user whether
it wants it now or later (Simon's original proposal and my current
implementation)
  * building the information about stanza importance (deliver now in-order, now
out-or-oder, or can be queued) into handlers, thus making Wocky more
intelligent about how to behave with handling the stanzas, but messing with
stanza ordering

(the in-between approach (specify stanza importance for each handler, but
always do in-order) sounds to like it has drawbacks of both of these
approaches).

The former solution is simpler (less chance to mess up) but requires the user
to know the stanza details in order to specify what to queue. The latter would
probably have better performance (due to possibility of doing some things out
of order), but is more complex and (IMHO) might be a bit harder to reason about
later on.

So, we first need to decide what we want to do :-)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.