[Standards] roster views
waqas20 at gmail.com
Sat Feb 28 09:59:19 UTC 2009
On Thu, Feb 26, 2009 at 8:35 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> Matthew Wild wrote:
>> On Thu, Feb 26, 2009 at 2:57 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>> Matthew Wild wrote:
>>>> On Thu, Feb 26, 2009 at 2:33 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>>>> We had rough consensus that the server would not change its processing
>>>>> of your outbound presence, i.e., it would send your presence to your
>>>>> entire contact list, not only contacts in the group(s) you specify via
>>>>> roster views.
>>>> I was of the impression that it would also apply to outgoing
>>>> presences, and the filtered roster would essentially become your
>>>> roster for that session. I don't know what others think though.
>>> I could go either way. If roster views result in filtering of your
>>> outbound presence then they are essentially a replacement for (some of)
>>> what's now in privacy lists. I like that idea a lot because I don't like
>>> privacy lists. :)
>> As a user I like that idea a lot, because it cuts out privacy lists.
>> As a developer I like it a lot because it cuts out privacy lists :)
>> Roster groups/tags are pretty flexible. This combined with simple
>> blocking of users (and a way to enable/disable receiving messages from
>> people not on your roster) is all that is required in most cases I
>> believe, particularly for end-users.
>>>>> If people think this would be useful, I'd be happy to write a small spec
>>>>> about it. Right now I don't think this belongs in rfc3921bis but I could
>>>>> be persuaded to change my mind about that (e.g., it might make sense to
>>>>> have both roster versioning and roster views in the same core spec).
>>>> I think I already said somewhere that I believe this should be in
>>>> core, versioning should be a XEP. Requiring all implementations to
>>>> support versioning just feels wrong, and I tend to like smaller specs.
>>>> However I understand if others don't feel the same way.
>>> I think that either both versioning and views belong in rfc3921bis or
>>> neither does. The syntax of what's currently in XEP-0237 (using an
>>> attribute to indicate the version number) makes it difficult to split it
>>> out into a XEP, but I suppose that could be overcome.
>> That's funny, it wasn't like that last week... ;-)
> Yeah, then we decided to make it roster-specific as it was in the
> beginning, using an attribute. But we could change this:
> <query xmlns='jabber:iq:roster' ver='305'/>
> to something like this:
> <query xmlns='jabber:iq:roster'>
> <ver xmlns='urn:xmpp:rosterver' num='305'/>
>> I'm not too fussed, it's going to be somewhere at the end of the day,
>> doesn't really affect me where it ends up.
> Perhaps you're right that we'd better leave rosters alone and define
> both versioning and views as extensions. I'll give that some further
> Peter Saint-Andre
In their current form, the only thing roster views do is save
bandwidth in rare cases, which wouldn't be too useful for most IM
users (most people don't have 1000+ contacts, and are generally not
trying to save that much bandwidth, even on mobile devices). They
don't fit the partial roster activation they are being considered for,
and are not a replacement for privacy lists. I have often wanted to
appear offline to a select group of people, but that doesn't mean I
don't want to see their presence.
Partial roster activation is a much much more attractive feature for
me than partial roster retrieval. I would probably never consider
using partial roster retrieval for my jabber account.
Anyway, some things to consider for roster views:
1. More than one activated group at a time needs to work
2. They may be more useful if they worked based on filters on all data
associated with a contact, e.g., groups, subscription, hosts
3. IM users would obviously want to change the activated groups more
than once during a session, so that needs to be covered
Fabio Forno's email covers 1 and 2. As for the RFC vs XEP argument, my
personal opinion is to keep the RFC short, and have these in an XEP,
but I don't feel too strongly about that.
More information about the Standards