On Fri, Jan 25, 2013 at 6:09 PM, Vishesh Handa <[email protected]> wrote:
> > 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 ;) Cheers -- Martin Klapetek | KDE Developer
_______________________________________________ KDE-Telepathy mailing list [email protected] https://mail.kde.org/mailman/listinfo/kde-telepathy
