[Bug 23151] Chan.I. Room — properties of chatrooms and chatroom-like constructs

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=23151

--- Comment #30 from Jonny Lamb <jonny.lamb at collabora.co.uk> 2011-01-03 09:40:22 PST ---
(In reply to comment #28)
> 14:08 < smcv> jonnylamb: I think you're probably right, we should bring back 
>               Chan.I.Subject

Done.

> If a protocol has the concept of a room subject, but has a distinction between
> "no subject" and "subject = ''", or "subject not known yet" and "subject = ''",
> would Present be set at all times, or only when a subject is known, or only
> when a non-empty subject is known? My guess would be that Present would be set
> at all times (so it MUST NOT change), 

Yeah that's how I saw it when I added it. It merely states that this protocol
supports room subjects. I've added more documentation to this effect.

> Does Can_Set mean "the protocol allows me to try to set the subject" or "I am
> sufficiently privileged to actually set the subject"? If the former, it MUST
> NOT change; if the latter (which I assume is what you meant), obviously it
> might change. However, you can't actually tell the latter reliably in XMPP. I
> researched some MUC implementations a while ago, and they don't all interpret
> the informational flag in the same way :-( You can get pretty close, as Gabble
> currently does for the Tp Properties.

Well I'm currently giving it exactly the same value as the RW flag for the
"subject" Tp property in gabble, as you've seen. I'm not sure how to describe
that though -- what is a better name than Can_Set then?

> SetSubject should probably raise NotImplemented, not InvalidArgument, on
> protocols without a concept of subjects? (I assume that's what you intended
> InvalidArgument to mean?)

Actually I thought in the case of protocols which don't support UTF-8 subjects?
But I guess that's actually none for now? It's easy enough to add later I
guess. I'll change that to NotImplemented.

> NotCapable isn't the right error for insufficient privileges, you should use
> PermissionDenied. NotCapable is about e.g. Jingle capabilities.

Ah yes good point, I forgot about that. Changed.

(In reply to comment #29)
> RoomID seems unfortunately-named for the human readable version - I'd suggest
> RoomName so that we could add RoomID to this interface later as the UUID (if
> Target* disappears in favour of ContactID and RoomID in future...)

Done.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.