[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