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 > > inserted) > > - 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 anonymous > like this? Primarily it was about simplifying the API and data structures in client and server. > If you're trying hard to avoid transmitting too much data, what about > 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 structures. > > - 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 > > invalid. > > > > 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 > on. 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
