elementary-dev-community team mailing list archive

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

As for D-bus, I guess we'll have two different keys for passing file names
and buffers/streams too. It would be nice to allow mixing D-bus and regular
calls in one .contract as long as they don't overlap.

2012/9/25 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
>


-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary