Including: - Picture - Creator (and Handle) - CreationTimestamp - PasswordHint Separate to RoomConfig (I think) we also need an interface to define the capabilities of Room members and be able to set those, e.g. who can speak, what capabilities new member should get on joining, and how an operator can set those capabilities.
Also it's not very clear how long Description should be. e.g. a protocol which has an optional room property called Guidelines, could that be the Description?
http://cgit.collabora.com/git/user/danni/telepathy-spec.git/log/?h=roomconfig-42653 After thinking about it, I decided the Creator stuff was more closely related to the Chan.I.Room and Picture should be its own interface. I put PasswordHint on RoomConfig and a flag on Password indicating clients should check the hint.
Created attachment 53229 [details] [review] RoomConfig.PasswordHint A hint for the room password. Fixes:
Created attachment 53230 [details] [review] Room: Creator, CreatorHandle and CreationTimestamp These properties indicate who and when the room was created. Fixes:
Created attachment 53231 [details] [review] New iface: Channel.Interface.Picture Lets the users set/get the picture for a chatroom. Fixes:
Comment on attachment 53229 [details] [review] RoomConfig.PasswordHint Review of attachment 53229 [details] [review]: ----------------------------------------------------------------- Looks good.
Comment on attachment 53230 [details] [review] Room: Creator, CreatorHandle and CreationTimestamp Review of attachment 53230 [details] [review]: ----------------------------------------------------------------- Looks good!
Comment on attachment 53231 [details] [review] New iface: Channel.Interface.Picture Review of attachment 53231 [details] [review]: ----------------------------------------------------------------- Looks good, broadly speaking. ::: spec/Channel_Interface_Picture.xml @@ +1,5 @@ > +<?xml version="1.0" ?> > +<node name="/Channel_Interface_Picture" > + xmlns:tp="http://telepathy.freedesktop.org/wiki/DbusSpec#extensions-v0"> > + > + <tp:copyright>Copyright © 2010â2011 Collabora Ltd.</tp:copyright> I wonder why this is mojibaked in my browser. Is Splinter insufficiently UTF-8 clean? :/ @@ +73,5 @@ > + </tp:possible-errors> > + </method> > + > + <property name="Picture" tp:name-for-bindings="Picture" > + type="(ays)" tp:type="Avatar" access="read"> Do we maybe want to annotate this with EmitsChangedSignal: invalidates? @@ +75,5 @@ > + > + <property name="Picture" tp:name-for-bindings="Picture" > + type="(ays)" tp:type="Avatar" access="read"> > + <tp:docstring xmlns="http://www.w3.org/1999/xhtml"> > + <p>The picture representing this channel.</p> This property doesn't define what “no picture” looks like (though it's pretty obvious, I guess). The Account.I.Avatar.Avatar property does; maybe move that definition to the struct definition and then we're done?
> I wonder why this is mojibaked in my browser. Is Splinter insufficiently UTF-8 > clean? :/ Hmm, I'd be tempted to blame git-bz munging the mime type perhaps? > Do we maybe want to annotate this with EmitsChangedSignal: invalidates? I think this causes a problem where multiple handlers/observers are watching the channel, and now all have to call Get(). It's not like this signal will fire frequently. > This property doesn't define what “no picture” looks like (though it's pretty > obvious, I guess). The Account.I.Avatar.Avatar property does; maybe move that > definition to the struct definition and then we're done? Done.
Created attachment 53235 [details] [review] Document how no-data is represented in the Avatar type Fixes:
Comment on attachment 53235 [details] [review] Document how no-data is represented in the Avatar type Review of attachment 53235 [details] [review]: ----------------------------------------------------------------- ++
Merged.
Channel.I.Picture was never undrafted. Do implementations (client- and service-side) exist? Are they any good? (In other words: undraft or delete?)
I don't think I ever implemented it. There's only one protocol I know of that supports the feature.
Thanks, I'll delete this from the Telepathy 1.0 branch at some point, and WONTFIX this. It can come back if it's ever actually implemented.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/124.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.