[Standards] roster views

Waqas Hussain 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 :)
>
> Bingo!
>
>> 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.
>
> Right:
>
> http://xmpp.org/extensions/xep-0191.html
>
>>>>> 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:
>
> <iq>
>  <query xmlns='jabber:iq:roster' ver='305'/>
> </iq>
>
> to something like this:
>
> <iq>
>  <query xmlns='jabber:iq:roster'>
>    <ver xmlns='urn:xmpp:rosterver' num='305'/>
>  </query>
> </iq>
>
>> 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
> thought...
>
> Peter
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>

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.

--
Waqas Hussain



More information about the Standards mailing list