On 3 April 2011 12:37, Olli Salli <[email protected]> wrote: > I'm sorry that I didn't investigate how this is currently handled in KDE > Telepathy - I was under the assumption that this hadn't yet been > implemented as generally our nepomuk interaction is said to be "not > there yet".
My bad. To clarify that - the infrastructure is there (although not yet release quality), and the first release is going ahead without it simply because we'd like to get something released soon, and the Nepomuk stuff is holding things up (entirely my fault). > Could you really, really briefly summarize your solution in the > following key aspects: > > 1) is it so that there is a base notion of presence in NCO/PIMO and you > have extended it so that the specific Telepathy presence can > additionally be received? Yup. The Nepomuk NCO ontology stores a presence string and a presence message. Any app should understand these. The Telepathy ontology extension has a field for presence type (can't remember the name) which stores the enum value from Tp. This allows telepathy aware apps to have all the available information from a Telepathy SimplePresence property. > and if so > > 2a) how is the "I don't know anymore" presence invalidation issue > handled? does the presence disappear, or does it go to some "unknown" > value in all of the (extended) levels of presence stored? Presence state becomes unknown (in all appropriate Nepomuk properties). > and > > 2b) do you intend Nepomuk to be the only presence source, even for > Telepathy aware applications in KDE, so that all presence updates are > transferred through Nepomuk storage to consumers? For applications aware of Persons (our metacontacts) yes. When we are dealing with just the presence of a particular Contact (KDE-Telepathy language - think raw Contact, rather than part of a Person), then not necessarily. > 3) is it really considered efficient enough (say, by Nepomuk upstream) > to store there the presence updates of potentially thousands of > contacts, which can happen really often because of auto-away and > auto-idle features? unscientific tests (as in, my experience so far) suggests that there are not going to be significant performance issues. Theoretically, upstream would say that performance should be fine too. In practice, I'm hoping to do some more scientific tests (with the #ubuntu test case and similar extremes) once I'm back to hacking properly. If these tests do demonstrate a performance issue, then we'll try and solve it with the Nepomuk developers help. If that fails, then it will be necessary to look again at ways of bypassing Nepomuk for very transient data. However, my experience so far suggests that things are not very likely to be that disastrous. I'm well aware of the problems that people have had with tracker in a similar context, but happily things aren't nearly as problematic in Nepomuk land :). Hope this helps a bit. -- George _______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
