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