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

[Tristan Van Berkom <tristanvb openismus com>]

On Thu, 2011-07-07 at 18:31 +0200, Patrick Ohly wrote:
> On Thu, 2011-07-07 at 15:09 +0530, Chenthill wrote:
> > 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 ?
> 
> "need *not* worry", right?
> 
> Yes, I can imagine that this would work. Should we allow to enable or
> disable this client side? In other words, should we force the separate
> storing of photo data in all cases or is there a legitimate situation
> where a client might want to force the data to be stored inline?

It's possible but will need to be conditional, probably depending on
whether there is a staging directory available or not.

I'll start thinking about how this staging directory could be
implemented, I suppose the client needs to create one somehow
while opening the EBook, and only on the condition that the
backend can handle incoming data from a staging directory.

Possibly at book creation time one needs to specify an
actual directory for this (or has the option to specify
a directory)... 

How do remote backends handle uris from the local staging dir ?
perhaps the staged uris would be sent as ftp:// to the remote
backend but locally stored in a file:// uri... does the backend
need to participate in the formatting of the uris that will
be sent to it ?

Perhaps the backend needs to claim that it supports a list of
protocols for staging data (such as 'file','http','ftp' etc) ?

Cheers,
         -Tristan

> I can't think of one myself.
> 
> Note that once we introduce this mechanism (whether it is mandatory or
> not), all clients must be prepared to deal with PHOTO URIs. But this is
> not new, because there might already be contacts in current EDS with
> URIs.
> 
> The only change would be that clients get an URI for their *own*
> contacts even if those had inline data.
>