On Thu, 2011-07-07 at 20:39 -0400, Tristan Van Berkom wrote: > I now have a much simpler patch up on the openismus-work branch[0]. > (it's also in patch form on the bug[1]).
That looks a lot saner than the previous solution. Removing all the attempts to keep clients perfectly informed about file removal has paid off. I haven't done a detailed code review. I'd prefer to have the EDS experts do that. But perhaps one change first: this code seems useful for a variety of local backends. I think the bulk of it should be in the shared libedata-book library. > Also there is a strange use case worth pointing out: > > You are not allowed to use an addressbook generated uri as the uri > for another field of the same contact or another contact. > > So you are allowed to set multiple contacts photo fields > to point to "http://hostyouravatar.com/buster.png";, but you > are not allowed to do: > > /* Get that contact named "Elvis Presley" */ > PhotoContact *photo = e_contact_get (contact_a, E_CONTACT_PHOTO); > > /* Use Elvis's face on this new contact I'm creating */ > PhotoContact *new_photo = create_photo (photo->data.uri); > > e_book_commit_contact (new_photo); > > Not sure if that's an acceptable rule or not, if not then we > either need to add some complex code to implement internal > refcounting on the uris in the backend... or perhaps we > could trap the incoming shared uris and create copies > on disk instead... I would trap the incoming URI and create a hardlink under a different name. That'll share the data without requiring us to implement refcounting in the backend. > In any case, I think we could try to close this first and > then look at the staging directory feature separately, seeing > that this code will very easily scale from: > a.) "If the incoming photo is a binary blob" to... > b.) "If the incoming photo is a binary blob or > a uri inside the staging directory..." I agree. We can always do another iteration if the D-Bus overhead for storing photos becomes important. -- Bye, Patrick Ohly -- [email protected] http://www.estamos.de/ _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
![http://hostyouravatar.com/buster.png"](http://hostyouravatar.com/buster.png"){kind=link}