On Tue, 2012-11-06 at 10:25 -0800, Travis Reitter wrote:
On Mon, 2012-11-05 at 19:48 +0100, Patrick Ohly wrote:
> On Fri, 2012-10-26 at 21:04 +0200, Patrick Ohly wrote:
> > I'm attaching the current API revision, a README which gives
> > SyncEvolution specific information and two example scripts.
Firstly, sorry I haven't had more feedback for these emails. I've been
busy lately and didn't have much to say.
> The problem is that ReadContacts() is defined as returning the contacts
> in the requested range *at the time when the server processes the call*.
> This can lead to the following situation:
> - client receives "10 added at #0"
> - client calls ReadContacts(0, 10)
> - client receives "10 added at #0" (basically, 10 contacts were
> - client calls ReadContacts(0, 10)
> - server processes first ReadContacts(), returns initial 10 contacts
> - server processes second ReadContacts(), returns same data again
Why would the server send "10 added at #0" twice? Are the contacts
ordered on the server and the second signal meant they were inserted in
front of the original 10?
Exactly. Numbering the contacts seemed fairly natural because they are
sorted on the server.
In general, what is the goal behind keeping the contacts fully
Primarily it was about simplifying the API and data structures in client
If you're trying hard to avoid transmitting too much data, what
giving the contacts integer handles? That way, you don't have to worry
about being able to identify them uniquely, but transmission sizes
should be relatively small. It obviously doesn't scale quite as well as
the scheme above, but even specifying a few thousand contacts hopefully
shouldn't be too heavy.
I agree. The proposal with the new "id" property does that, except that
I went for strings instead of integers. It's more flexible that way, at
the expense of higher overhead.
> The other solution is to change the API as follows:
> - Introduce a separate string ID for a contact. This ID is assigned
> when a contact is first added to any view (i.e., it is the same in all
> views) and reported to the client as part of an extended
> "ContactsAdded" signal:
> void ContactsAdded(object view, int start, array ids)
> New contacts were added to the view. The number
> of new contacts is given via the size of the ids array.
> The ID of each new contact is guaranteed to be the same
> in all views. IDs may get reused after their contact got
> removed from the last view it was contained in. In
> particular there is no guarantee that it is persistent
> across restarts of the PIM manager.
> The contact which previously had index #start now
> has index #start + count, etc.
I would encourage not re-using an ID during a single session, if
possible. Telepathy makes this unlikely by incrementing contact handles
indefinitely until they overflow the storage type (which would pretty
much never happen in a single session, so it shouldn't be an issue).
My preliminary implementation just exports the FolksIndividual id. That
avoids another layer of indirection inside the server. Does that ensure
that IDs are not getting reused during a session? The folks
documentation doesn't specify that.
I don't know yet whether I'll stick to that. I still have it in the back
of my head that it might be useful to expose search results directly
from EDS as interim solution while folks still builds up its data
> - The string ID becomes part of the contact dictionary:
> "id" = an opaque string which identifies the contact while it
> exists inside any PIM Manager view. See ContactsAdded and ReadContacts.
> - Change the ReadContacts() call so that it takes an array of these IDs
> to determine which data is requested:
> list of (int index, contact dicts) pairs ReadContacts(array ids)
> Requests the data of the contacts idenfified via their IDs.
> Only the data of contacts that are still part of the view
> can be returned.
> The returned list contains the current index of the
> requested contact plus its data. -1 and an empty
> dictionary are returned for contacts which can no longer
> be read, for example because they were removed from the
> view in the meantime or because the ID was simply
> Note that the caller must process the call response after
> all events via the ViewAgent interface. Otherwise the
> index numbers are potentially out of sync and thus
> unreliable. Doing this call asynchronously and dealing
> with the response as part of the main event loop will do
> the right thing automatically, because D-Bus guarantees
> ordering of messages.
> Making this explicit by returning data via another
> org._01.pim.contacts.ViewAgent method was considered and
> rejected a) for the sake of keeping this API simple and
> b) to allow simple synchronous calls where it makes sense
> (testing, for example).
> Does this make sense?
If you don't think it would lead to performance issues for your needs,
I'd recommend a string ID. It gives you a lot of flexibility, can be
somewhat human-readable (ie, developer-readable) when debugging, and so
That was also my thinking.
And, depending upon your transmission medium, there may be minimal
impact on transmission sizes (eg, if you're pushing integers through XML
at some point, like for D-Bus, your transmission envelopes will add a
lot of bulk relative to the size of the IDs in many cases).
Transmission is via D-Bus.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.