Re: [Evolution-hackers] improve PHOTO support in libebook/EDS

[Patrick Ohly <patrick ohly gmx de>]

On Wed, 2011-07-06 at 16:16 -0400, Tristan Van Berkom wrote:
[staging directory for out-of-band photo data transmission]
> This alternative proposal is strictly regarding the photo data for
> which the server must take ownership of I assume, correct ?

Yes.

> I might not have been clear enough in my proposal but I only 
> intend for new or modified photos to be sent to the addressbook.

Understood. I personally don't mind the D-Bus overhead in these cases
because I consider them rare. But there are people who run massive write
benchmarks against EDS anyway and do flag low performance in them as a
problem. So if we can find a solution that also optimizes the write
performance, then it would be better.

> The staging directory you propose if I understand it correctly
> would also be used under only the same circumstances, I suppose
> the questions are:
>   o What is faster: writing a file to a staging directory and 
>     then moving it to a permanent location or sending the blob
>     once over D-Bus and saving it to the permanent location.

If the photo data needs to be stored as file and moving the file into
its permanent location can be done with a rename, then the staging
directory approach is faster. I expect writing the file to be equally
fast, regardless of who does it. Sending inline data adds D-Bus overhead
(considerable for large chunks of data!) and encoding/decoding overhead.

>   o What is more reliable ? (it seems that there are less
>     points of failure when sending the blob but I could be wrong).

Agreed. I tried to mitigate that with the rules around cleaning up the
staging directory.

> Perhaps the staging directory is a little faster when batching lots 
> of photo modifications during a 'sync' operation ? (the client
> gets to write to disk while waiting for the server to be ready
> for the next batch of contact additions perhaps ?)
> 
> At any rate, if it's judged that the performance gain of using
> a staging directory is worth the added complexity then let's do it.

I'd like to hear some other opinions about this. Ross?

> I think the more important issue at hand is that to offer
> a reliable api for EBookView then the backend has to track
> the views which have received notification of the contact
> modifications.
> 
> In other words when I have an EBookView and I have been
> notified that a contact exists with a photo at a given uri path,
> then until I receive notification that that uri is invalid,
> removed or replaced with a new one... I should be able to
> access that file.

I don't see this as a problem. When a process fails to load a photo
because the contact was already removed on the server together with that
photo, then shortly after the attempt to read the photo the process will
get the notification that the contact is gone and thus the process no
longer needs the photo.

I also think that this is a very rare situation. Definitely doesn't
justify adding complex code to the D-Bus interface between libebook and
EDS.

> Another hard limitation is regarding storing uris for which
> you don't want the addressbook to assume ownership of.
> 
> The clean way as far as I can see is whoever is responsible
> for adding an 'alien uri' to an addressbook is responsible
> for removing that entry from the addressbook at the time
> that the uri might be deleted.

Agreed. But I don't think there is a clean and efficient way of solving
this. It'll be much simpler to accept that there will be URIs that point
to deleted files.

The intention is to not use URIs pointing to arbitrary local files.
Therefore we don't need to provide a solution that assists apps who want
to do that.

> Well... perhaps we should just swallow the ugly race and do nothing
> about it and say that:
>   "a uri might be invalid from time to time directly before your view
>    receives notification of the removal" ?
> 
> Would that be acceptable ?

Yes.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/