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

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

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to