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

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

-- 
Best Regards

Patrick Ohly
Senior Software Engineer

Intel GmbH
Open Source Technology Center               
P├╝tzstr. 5                              Phone: +49-228-2493652
53129 Bonn
Germany

_______________________________________________
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers

Reply via email to