GNOME Bugzilla – Bug 548276
Future proof organisation of the roster: support for default categories (rfc4480)
Last modified: 2008-09-18 12:02:21 UTC
Hello, Actually the roster can add any categories the user may choose. This will lead to an unlimited amount of various categories and language translation issue in the future if we plan to support rich presence for the SIP protocol as defined here: http://www.ietf.org/rfc/rfc4480.txt The support for this RFC might be not so far away, as a partial support can introduce avatar support in Ekiga. Support for this RFC can also be considered as the future of presence protocols as it introduce the notion of group in the IM part of SIP (an as been designed with interoperability with XMPP in mind), which is IMHO a "killer" feature. This RFC define the notion of "Relationship Element": "3.9. Relationship Element The <relationship> element extends <tuple> and designates the type of relationship an alternate contact has with the presentity. This element is provided only if the tuple refers to somebody other than the presentity. Relationship values include "family", "friend", "associate" (e.g., for a colleague), "assistant", "supervisor", "self", and "unknown". The default is "self". If a relationship is indicated, the URI in the <contact> element refers to the entity, such as the assistant, that has a relationship to the presentity, not the presentity itself." I propose to add a list of available choices categories by default when adding a contact in the roster: - family - friend - associate - assistant - supervisor - self - Add a new category... Add a new category allow to add new categories which will be under the label "unknown" for future proof support of this RFC. If one of this categories is empty it should not appear in the roster. This feature enhancement will also help user use the roster in a well organised manner. Best regards, Yannick
I'll add the feature to the local roster.
Good idea. Don't forget to mark for translations. I also had another idea this week-end : - what about adding an Ekiga.net category with : * 500@ekiga.net (Audio test) * 501@ekiga.net (Conferencing System)
- what about adding an Ekiga.net category with : * 500@ekiga.net (Audio test) * 501@ekiga.net (Conferencing System) +1
+1 - ekiga.net category should be visible by default (and the user can remove them if hw wishes)
what about adding an Ekiga.net category? It should only appear if you have an ekiga.net account, if you do not have one, those numbers wont work...
I would always display it. That can encourage people to subscribe for an account. Checking if the user has an ekiga.net account is difficult and hackish. Those default entries would be added at startup, when the roster is empty. At that time, in general, there will be no ekiga.net account as the account will be created at a later stage.
I suggest to add that in ekiga.schemas.
Notice : if 500 and 501 don't work for unregistered users, having them in the roster and fail without explanation will lead directly to "This crappy app doesn't even work with its own default testing targets!"...
Fixed in my post3 branch.