KTp/Components/Buddy List: Difference between revisions
< KTp
Grundleborg (talk | contribs) (correct t-i-d link) |
Grundleborg (talk | contribs) (add some braindump on how we use Nepomuk) |
||
Line 18: | Line 18: | ||
Why this way? Basically, we've tried every other possibility that we can think of (we being George and the Nepomuk folks mainly in this case) and all the other ideas fall apart at some point, whereas this one seems to be OK so far. | Why this way? Basically, we've tried every other possibility that we can think of (we being George and the Nepomuk folks mainly in this case) and all the other ideas fall apart at some point, whereas this one seems to be OK so far. | ||
== How we Use Nepomuk == | |||
* Meta contacts are represented by a PIMO:Person | |||
* Contacts are represented by a NCO:PersonContact | |||
* PIMO:Person are only created when a user explicitly defines two NCO:PersonContacts to belong to the same Meta Contat. | |||
* For NCO:PersonContacts without a PIMO:Person, the contact list UI generates a fake meta-contact with only one constituent child contact. | |||
* Groups are treated like tags (no hierarchy). NCO:ContactGroup is used to represent them in Nepomuk. | |||
* If a contact changes group on the server, if the meta contact it belongs to has all its subcontacts also in the same group, it is also moved. If only one of its subcontacts has moved group, leaving it with children in two or more groups, it stays in the original local group, and an overlay is displayed, which when clicked, allows the user to resolve the conflict in the various possible ways. | |||
* Telepathy ontology (installed by telepathy-integration-daemon) is a temporary dumping ground for all extensions we need to the standard Nepomuk ontologies. Before we make any release, it should be reviewed by the Nepomuk developers and as much of possible of what it contains (ideally all of it) should be upstreamed to the Nepomuk ontologies. |
Revision as of 15:54, 25 March 2010
Braindump
- use nepomuk for displaying everything.
- Nepomuk meta-contacts
Code
Skeleton Implementation, that displays a rough buddy list, but doesn't do much else can be found at:
svn://svn.kde.org/home/kde/trunk/playground/network/telepathy-contactlist
Design
- telepathy-integration-daemon pushes contacts into nepomuk and keeps them in sync with the servers through telepathy. It will get all contacts and their details when you initially connect to a account, and then it will (check periodically?) make sure that they stay up to date in nepomuk when they change on the server. It will also keep all contacts' presence set in nepomuk.
- buddy list is populated entirely from nepomuk. it only talks to Telepathy when requesting a channel to someone (ie you double click on them to chat or something). Even presence information comes from nepomuk. Metacontacts are also implemented in Nepomuk.
Why this way? Basically, we've tried every other possibility that we can think of (we being George and the Nepomuk folks mainly in this case) and all the other ideas fall apart at some point, whereas this one seems to be OK so far.
How we Use Nepomuk
- Meta contacts are represented by a PIMO:Person
- Contacts are represented by a NCO:PersonContact
- PIMO:Person are only created when a user explicitly defines two NCO:PersonContacts to belong to the same Meta Contat.
- For NCO:PersonContacts without a PIMO:Person, the contact list UI generates a fake meta-contact with only one constituent child contact.
- Groups are treated like tags (no hierarchy). NCO:ContactGroup is used to represent them in Nepomuk.
- If a contact changes group on the server, if the meta contact it belongs to has all its subcontacts also in the same group, it is also moved. If only one of its subcontacts has moved group, leaving it with children in two or more groups, it stays in the original local group, and an overlay is displayed, which when clicked, allows the user to resolve the conflict in the various possible ways.
- Telepathy ontology (installed by telepathy-integration-daemon) is a temporary dumping ground for all extensions we need to the standard Nepomuk ontologies. Before we make any release, it should be reviewed by the Nepomuk developers and as much of possible of what it contains (ideally all of it) should be upstreamed to the Nepomuk ontologies.