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

[Patrick Ohly <patrick ohly gmx de>]

On Fri, 2011-07-08 at 14:45 -0400, Tristan Van Berkom wrote:
> 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.

I don't think EDS ever made the promise that an items would be saved
exactly as sent. Apps which need an exact copy of the stored item indeed
should use a view to get the real content of the database after
requesting changes.

> > > 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).

This is also what I had in mind.

> But it seems more practical to leave file uploading to the client,

We can design the API to make that possible, but I don't think we should
worry to much about it now.

> 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).

Do we want one staging directory per address book, or one staging
directory per client? My proposal was to create one per client, because
then client's don't have to worry about file name collisions (they are
the only ones writing into it) and files can be deleted once the client
exits. If we have a long-running user of the address book (like
Evolution) and a short-lived one (like SyncEvolution) and only one
staging directory, then files created and not properly committed by
SyncEvolution cannot be cleaned until also Evolution quits.

It might also be advantageous to have one directory per client process
once MeeGo adds separate privileges for processes running under the same
user ID. This is currently a pie in the sky, though.

Note that the "private staging directory" is a bit at odds with allowing
arbitrary URIs. While such a guarantee is easy for local directories, it
might make less sense for other URIs (like HTTP resources + PUT). This
could be resolved by making the guarantee only for file:// URIs.

>    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 ?

I think it is doable.

-- 
Bye, Patrick Ohly
--  
Patrick Ohly gmx de
http://www.estamos.de/