elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

Hey guys,

Following up on Contractor
issues<https://docs.google.com/document/d/1kjpIHASnkcFnbzFp_Hs5ikeciK_t4YVdZfn4WCKai4c/edit>document
and passing
text buffers <https://bugs.launchpad.net/contractor/+bug/1025341> in
particular, it appeared to me that we might need to pass any type of data.
So I've finally sat down and listed all the ways to pass data from one
process to another along with their applicability to Contractor use case,
the doc is available at
https://docs.google.com/document/d/1_w6-XBtr9qXXteytC9Mz0JqXZZoMsOPdfTDXVcoswUY/edit#

I suggest we support all three direct transfer mechanisms, because each of
them has a distinct use case and they're all supported by some provider
apps.
As for pointer-based mechanisms, I think we should support only files;
named pipes are needed only for faking streaming support that can be done
in a wrapper script, and everything else is either too limited or not
designed for our use case.

For stream handling we'll also need a way of indication that the service
provider expects data streams/buffers, not files.
I suggest we add the following keys to the .contract file format:

   1. Something like 'StreamExec' for the command to run when passing data
   in stream mode
   2. A 'StreamFormat' key, similar to all those % values in Exec
key<http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html>in
.contract and .desktop files
   3. An optional 'StreamFileDescriptor' key that specifies the file
   descriptor on which the service provider expects client data. It's 0
   (standard input) for the vast majority of apps, so let's make it optional.

I suggest avoiding faking stream support for file-based contracts and vice
versa, because that can be easily faked in a wrapper script, and the same
contract may exist in two different versions, e.g. in case streaming
doesn't support all the mimetypes that passing files does. In short: leave
that to the .contract author.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary