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

[Tristan Van Berkom <tristanvb openismus com>]

On Fri, 2011-07-08 at 12:49 +0200, Patrick Ohly wrote:
> On Thu, 2011-07-07 at 20:54 -0400, Tristan Van Berkom wrote:
> > 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.
> 
> The EDS daemon needs to create the directory. That's required for the
> cleanup rules to work. I would do it in the backend, possibly with some
> server-side utility code that can be used by multiple backends.
> 
> > Possibly at book creation time one needs to specify an
> > actual directory for this (or has the option to specify
> > a directory)... 
> 
> The backend should choose. That way it can pick something that is
> suitable (like on the same filesystem) without exposing implementation
> details to the client.
> 
> > How do remote backends handle uris from the local staging dir ?
> 
> They'll simply refuse to create a staging directory and thus request
> that the client continues to inline data.
> 
> > 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 ?
> 
> That is one possibility. Don't forget that the local file backend also
> has to rewrite the URI (from staging dir to final location).

Right,
   that should work in the same way that it currently works
with incoming binary blobs: The blob or staged uri gets
transformed before being stored in the BDB... only after
that do any notifications get sent (so the notifications
already come with the properly transformed contact).

However the EContact passed to e_book_commit_contact()
will not be modified by the call to the backend (the 
gdbus call simply queues a job in the addressbook thread
and returns)... so for the caller to get the real uri
one must further call e_book_get_contact() or have an
EBookView in play to receive it.

> 
> > Perhaps the backend needs to claim that it supports a list of
> > protocols for staging data (such as 'file','http','ftp' etc) ?
> 
> The staging dir would be, by definition, local. I don't think we should
> support anything else.
> 

Ah I had imagined it the other way around (that the addressbook
would take care of downloading any data from a client's directory).

But it seems more practical to leave file uploading to the client,
then as you say managing the directory becomes more straight forward
and also at initialization time I suppose the backend only needs
to report a staging uri.

All in all then the added code I think would be:

   o An api for a client to get a staging directory
     (which can return NULL)

     const gchar *e_book_get_staging_uri ();

     The api would be implemented with a new GDBus
     method call or property which would in turn
     be handled by EDataBook.

     EDataBook would implement it in a backend
     specific way and return NULL if the backend
     does not implement the new ->get_staging_uri()
     vfunc.

   o EBookBackendFile (the BDB addressbook backend) will then
     manage a staging directory and implement the new vfunc:
     EBookBackendClass->get_staging_uri() to report the
        file://path/to/staging/directory/

     "Managing" the staging directory will only consist of creating
     it at book creation time, removing it at book remove time and
     emptying it out every time the book is freshly opened (just in
     case).

   o The local file backend will then move files from the staging
     directory to the 'photos' directory and update the uris
     in the stored vCards (whenever receiving vCard updates that
     refer to files in the staging uri).

     If the addressbook receives uris in the staging directory which
     have failed to upload or do not exist for any reason that will
     be considered an error (the client needs to finish uploading
     successfully before sending vcards holding staged uris of course).

Clients can then try to get a staging uri, if they receive a staging
uri then they should check if they support the protocol.

If the backend returns an ssh:// staging directory and the client cannot
deal with that, then the client should fall back to sending binary
blobs (whether or not there is a staging directory available, clients
can continue to send photo data as binary blobs reliably anyway).

In theory clients can deal with the addressbook owned staging uri
pretty conveniently using GIO to check if the staging uri is supported
and to upload data.

Perhaps this is not so very complex after all ?

Cheers,
     -Tristan