On 2/15/10 9:35 AM, Christopher Orr wrote: > On 11/02/2010 05:20, Peter Saint-Andre wrote: >> On 2/10/10 6:39 PM, Joe Hildebrand wrote: >>> Aside from the whitespace ping adjustment (which is cool), I think SIFT >>> (XEP-273) does roughly the same thing. Should we add ping optimization? >> >> At the Summit, some folks discussed the idea of a minimal feature for >> hushing the session. Perhaps that would be enough (not even requiring >> something like SIFT). > > Unfortunately I left the Summit just as that discussion seemed to start! > > Anyway, I think Google's 'queuing' example complements the ideas in > XEP-0273. For presence stanzas in SIFT (section 4.1), "the server shall > resynchronize the client regarding the presence states of its contacts" > when the client disabled presence SIFT. This is roughly analogous to > (albeit not as nice as) the <flush/> command in Google's implementation.
Indeed.
> XEP-0273 seems reasonable to me overall. For example, an application
> like Buddycloud might want to use SIFT to filter out all <iq/> or
> <message/> stanzas, except for those in select pubsub namespaces. At
> the same time, being on mobile, they could SIFT all ('hush') <presence/>
> in order to preserve battery life.
That's the idea, yes.
> Perhaps to include the ideas from Google's queuing example -- allowing
> delayed delivery of presence (or indeed any stanza type) -- an extra
> attribute could be added to SIFT's <allow/> tag. This would let the
> client indicate when it is willing to receive unfiltered stanzas, like
> Google's flush-when-queue-is-full implementation.
Maybe we need to change "SIFT" to "SHIFT" -- stanza hold, interception,
and filtering technology. :)
I don't see why you would hold IQs for later delivery, and messages
would get sent to offline storage so you could retrieve them later.
> So <allow/> with an extra attribute:
> send='when-q-is-full' => as per Google's server-side bounded queue
> send='with-others' => only send when other stanzas are being sent
Can't the client simply cancel any previous sifting to receive stanzas
again?
> send='always' => do not queue stanzas; the current SIFT default
>
> The intent of bunching stanzas together 'with-others' would be to
> minimise mobile device wake-ups and thereby reduce CPU/radio/battery usage.
Yes, that is the main goal of SIFT.
> As a minimal example, the following SIFT config from the client would
> instruct the server to only forward <presence/> stanzas when it's about
> to send a <message/> or <iq/> to the client:
>
> <sift xmlns='urn:xmpp:sift:1'>
> <presence>
> <allow send='with-others'/>
> </presence>
> </sift>
>
> Similarly for the Buddycloud example above, where pubsub events are
> likely more important than having up-to-date presence:
>
> <sift xmlns='urn:xmpp:sift:1'>
> <message>
> <allow name='event' ns='http://jabber.org/protocol/pubsub#event'/>
> </message>
> <presence>
> <allow send='with-others'/>
> </presence>
> </sift>
>
> Again as with the Google queuing example, it would be nice to have an
> explicit 'flush' command. This could be used, for example, if the
> client has presence SIFTed entirely (since the mobile device is idle and
> in the user's pocket 95% of the time) but wants to do a quick
> presence/pubsub/whatever sync with the server when the user starts
> interacting with their device.
>
> Perhaps all of this isn't quite as minimal as whatever was discussed at
> the Summit.. ;)
What we discussed (briefly) at the Summit was a truly minimal "hush"
command to block inbound presence:
<iq type='set'>
<hush xmlns='urn:xmpp:hush:0'/>
</iq>
Along with a corresponding "unhush" command to allow presence again:
<iq type='set'>
<unhush xmlns='urn:xmpp:hush:0'/>
</iq>
The reasoning was that most of the time a client just wants to turn off
presence. No need for the complexity of SIFT in that situation.
> But having read XEP-0273 plus Jonas's information from Google, I thought
> there were complementary elements to both and the above seems like
> reasonable example of the practical uses (a version of) SIFT could provide.
Quite possibly, yes. I need to think about it some more.
Peter
--
Peter Saint-Andre
https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
