On 3/18/09 8:19 AM, Fabio Forno wrote: > A quick recap about all the discussions we had since Brussels and some > new thoughts on roster optimizations > > - Roster sequencing rocks, it should be inserted into rfc3921bis and > all the world will implement it
Last Call in progress. :) > - Partial roster retrieval: it's not clear whether it should be just > retrieval or something modifying also the behavior of presence > broadcast. I'd prefer to stick it just retrieval, without affecting > presence and implement it as an optional xep, letting what I call > "activation" to a different mechanism. The main reason is that these > are two different things which can be needed in different situations; > partial retrieval has sever distinct use cases, which are independent > from presence delivery: > - just discover the groups > - retrieve just a group > - retrieve accordingly the subscription state (I feel this is pretty > important since I don't want to retrieve 1000 contacts with > subscription == none on my mobile, as it can happen if I use the > roster as address book for contacts I have very infrequent > communications with) > - retrieve additional information bound to contacts (certificate, vcard, ...) That sounds like a reasonable approach. > - About partial roster activation there are different points of view, > some say it's not necessary, some is fearing a new monster like > privacy lists, others say just use privacy lists! The only thing I'm > sure about it is that we need it, since from few tests when I go > online with my mobile (compression enabled), I get the following > figures: > - ~ 1.5 KB for logging in with all the stream features and sasl thing > - ~ 4-5 KB for a ~ 150 contact roster > - ~ 12-14 KB for the inbound presence storm, most of it completely unwanted. > > So we did some internal brainstorming and here is what is our > implementation plan: > - privacy lists have the nice feature of being there and ready, so we > will use them > - we don't implement them, but just use them, that's to say users > will be not aware of the existence of such a baffling thing like > privacy lists, we just add a group "VIPs" (an perhaps some other more > in future) and the the user: if you want to save bits just add there > all the people you want to see whether they are only or not > - If the VIPs group has items we create a privacy list in which all > incoming presence is blocked but that of VIPs > - Before going online we set the VIPs privacy list as the active one > > The only problem is that if we want to probe some contacts not in them > VIPs group we must either put them temporarily in the VIPs group or > unset the privacy list, and I don't know if there ar workarounds for > this (but a service with which we can poke the presence of somebody > using an <iq/> Another possible hack is to create a "temp" group and add/subtract people in that group (leaving VIPs alone). Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
