Allow optional data to be passed along requests and responses

[gonzalo-bulnes]

Just taking note of a pattern for now, we can elaborate and turn this into an actionnable issue when useful.

In the context of #105, @rocodes and I briefly considered the possibility of returning some additional data along the response codes that are printed to STDOUT. Namely, we discussed how providing a list of device identifiers of some sort when multiple devices are found, and allowing for an optional device identifier to be passed as a command parameter would allow to support that scenario, by allowing consumers (e.g. the SecureDrop Client) to specify which device the file(s) should be exported to. (The presence of more than one export device is currently treated as an error.)

I am seeing a similar pattern emerge in freedomofpress/securedrop-client#1584. This time, allowing an opaque identifier to be optionally passed alongside a request, for it to be included in the response, would allow to support requesting multiple printing jobs concurrently (concurrently from the perspective of the SecureDrop Client, the printing queue on this side would serialize them). It would be some kind of printing job identifier in that specific case, but this code wouldn't gave to know that, the piece of data could be completely opaque. (details)

The pattern I identify is: allow some optional data to be passed along requests/commands, and allow some data to be included alongside the response code in the responses.

cc: @rocodes @eaon @cfm

[rocodes]

I'm feeling a little cautious about trying to stuff more complex data structures into qrexec commands. I think it's a good idea to figure out how we will support scenarios like exporting with more than once device, or serializing print jobs, but I think we should figure out the most 'qubes-native' way to do it.

The features of the workstation that feel the most like scope creep to me are the ones where we are trying to re-implement the management of peripherals, and they also seem to be the ones that cause the most grief/inordinate amount of developer time... so I would want to think this through in conjunction with some of the other conversations we're having about if we could make more/different use of the features of QubesOS to serve some of these purposes, and/or if we can envision getting to a place where we don't have to, for example, prompt for disk passphrases via sd-app.

I would like to talk about this as a broader topic, though!

[eaon]

Overall with some of the things we want to do in the future, I think this won't just be a nice to have but a requirement. That being said, I'm with @rocodes on being cautious about adding complex data structures to the output now.

I've pointed to this before in the past, but I'm of the opinion that we want actions like export/print to be RPC calls (the intent of this issue being just one aspect for that preference) and use the same format for serialization/deserialization on both ends. I would really like to see something like a Protocol Buffers or Message Pack based specification/protocol to be used for that, so we get the flexibility to have in-band binary data but also strong "easy-to-deserialize" types.

So yes, 💯 something we want to have a broader discussion about, and IMO probably another "system" that we could standardise on to aid multiple upcoming features.