[Standards] roster views

Matthew Wild mwild1 at gmail.com
Thu Feb 26 03:09:26 UTC 2009


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... ;-)

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.

Matthew



More information about the Standards mailing list