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