Re: [Evolution-hackers] improve PHOTO support in libebook/EDS
- From: Patrick Ohly <patrick ohly gmx de>
- To: Tristan Van Berkom <tristanvb openismus com>
- Cc: Evolution Hackers <evolution-hackers gnome org>, Ross Burton <ross burton intel com>, Murray Cumming <murrayc openismus com>
- Subject: Re: [Evolution-hackers] improve PHOTO support in libebook/EDS
- Date: Fri, 08 Jul 2011 13:02:19 +0200
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
--
Patrick Ohly gmx de
http://www.estamos.de/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]