[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-telepathy
Subject: Re: Metacontacts/KPeople status
From: Martin Klapetek <martin.klapetek () gmail ! com>
Date: 2013-01-30 9:17:08
Message-ID: CAPLgePok=EHjt+vc+DYGs+D_foPQM=Tp5UG9aPQa2nwhuZY_wg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jan 25, 2013 at 6:09 PM, Vishesh Handa <handa.vish@gmail.com> 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
[Attachment #5 (text/html)]
On Fri, Jan 25, 2013 at 6:09 PM, Vishesh Handa <span dir="ltr"><<a \
href="mailto:handa.vish@gmail.com" \
target="_blank">handa.vish@gmail.com</a>></span> wrote:<br><div \
class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><div \
class="gmail_quote"><div>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.<br>
<br>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.<br></div></div></div></div></blockquote><div><br></div><div>
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).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_extra"><div class="gmail_quote"><div> <br></div><div>Here is \
the data that we currently have -<br>
<br></div><div>1. Basic contact data such as nickname, fullname, and other \
details<br></div><div>2. Contact groups and grouping \
information<br></div><div>3. Meta-contacts information: This person \
consists of these contacts.<br>
<br></div><div>Does Akonadi need any of this \
information?<br></div></div></div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_extra"><div class="gmail_quote"><div><br></div><div>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.<br>
<br></div>Synchronization is hard problem. In this case it does not seem \
like really we need to synchronize \
anything.</div></div></div></blockquote><div><br></div><div>So for now, \
I'll do just editing on Nepomuk level, ok?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_extra"><div class="gmail_quote"><div \
class="im"><br><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> * contact's offline presence</div>
<blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div>- 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.</div>
</blockquote></blockquote><div><br></div></div><div>Storing the presence in \
Nepomuk seems to cause more problems than it solves. Does it really solve \
anything?<br></div></div></div></div></blockquote><div><br></div><div>
Not anymore, with my super awesome presence model.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div \
class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>We have all the data to fetch the presence in real-time \
- account identifier, and the contact \
identifier.<br></div></div></div></div></blockquote><div><br></div><div>Exactly.</div><div> \
</div><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div \
class="im"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote \
style="margin:0 0 0 40px;border:none;padding:0px">
</blockquote> * good startup time<blockquote style="margin:0 0 0 \
40px;border:none;padding:0px"><div>- 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.</div>
</blockquote></blockquote><div><br></div></div><div>I can help with this \
:)<br></div></div></div></div></blockquote><div><br></div><div>Splendid. \
I'll contact you ;)</div><div><br></div></div><div>Cheers</div>-- <br>
<div><span style="color:rgb(102,102,102)">Martin Klapetek | KDE \
Developer</span></div>
_______________________________________________
KDE-Telepathy mailing list
KDE-Telepathy@kde.org
https://mail.kde.org/mailman/listinfo/kde-telepathy
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic