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

[Chenthill <pchenthill gmail com>]

On Thu, 2011-07-07 at 10:48 +0200, Patrick Ohly wrote:
> 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.
I like the staging directory approach. Would it be possible for
implementing the logic to convert the inline data ->file inside 
e_book_client_add_contact so that the clients need to worry about
changing the code ?

- Chenthill.
> 
> >   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.
>