If we decide to only writeback changes back to Nepomuk. It will result in us having 2 additional processes which monitor the Nepomuk store for changes (not that cheap) and keep writing back to Akonadi and Telepathy. Additionally, we already have a process in Akonadi which writes data to Nepomuk, and the same for Telepathy.

Do we really want 4 process continuously synchronizing all the data? It seems like a massive waste of cycles. Also, it doesn't really accomplish anything.

Two things I'd like to note here - the writeback would be quite sparse - there won't be that much contact editing. Also one at the time at most. So arguably that wouldn't be /that/ massive waste of resources. I also agree that "one directional" feed is better (changes done directly in backends like telepathy, refeeded into nepomuk through feeders).

Here is the data that we currently have -

1. Basic contact data such as nickname, fullname, and other details
2. Contact groups and grouping information
3. Meta-contacts information: This person consists of these contacts.

Does Akonadi need any of this information?

1. and maybe 2. I think. If you change a name of the (email) contact, you surely do want this to have in Akonadi I guess. Unless we port everything to KPeople (KMail and friends), which might be the ultimate goal, but...someone needs to do it.

My take would be to just write the data back in Telepathy (if possible), and let Nepomuk update itself from the feeder, or manually update Nepomuk. Both approaches work fine.

Synchronization is hard problem. In this case it does not seem like really we need to synchronize anything.

So for now, I'll do just editing on Nepomuk level, ok?

* contact's offline presence

- for the contact list to work properly with kpeople, one needs to have the ktp-nepomuk-feeder running ALL the time. Once it's down, we're screwed. Currently there's a different problem though - when the service shuts down (logout or reboot for example), it leaves all the presences in Nepomuk in whatever state they were. This means when you relogin and run the contact list, all the contacts have wrong presences until the feeder kicks in and puts correct data into Nepomuk. If the feeder for whatever reason won't start, the user is left with random invalid presences. It could write offline presence while being destroyed, but that would need to be synchronous job which can take some time, which means delaying reboot/logout/whatever for no apparent/visible reason to the user. We were talking if we could reuse KTp presences as we have them available in almost realtime, but that means combining two models (where one queries the other) and I don't like that very much.

Storing the presence in Nepomuk seems to cause more problems than it solves. Does it really solve anything?

Not anymore, with my super awesome presence model.

We have all the data to fetch the presence in real-time - account identifier, and the contact identifier.

Exactly.

* good startup time
- currently we're at ~3 secs before contact list shows up with ~800 contacts. I'll investigate where's the holdup and see what we can do about it.

I can help with this :)

Splendid. I'll contact you ;)