On Thu, Feb 26, 2009 at 8:35 AM, Peter Saint-Andre <stpe...@stpeter.im> wrote: > Matthew Wild wrote: >> On Thu, Feb 26, 2009 at 2:57 AM, Peter Saint-Andre <stpe...@stpeter.im> >> wrote: >>> Matthew Wild wrote: >>>> On Thu, Feb 26, 2009 at 2:33 AM, Peter Saint-Andre <stpe...@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
