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? In general, what is the goal behind keeping the contacts fully anonymous like this? 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. There are other options to minimize the impact here as well, like having a special notation that means "all contacts". Or supporting a syntax that allows multiple ranges. At any rate, Telepathy uses this concept of integer IDs at the lowest level, but I believe it's been moving away from it in recent iterations. You might want to ask the Telepathy maintainers why. > 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). > - 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. 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). Regards, -Travis
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
