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. > _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
