Reduce the number of layers our commands go through

[kvark]

Here are the current stops in a one-way trip of a client command:

1. render::Client::do_something() creates a Cast or Call message and sends it through the pipe
2. render::Server receives the message and calls some the device::Client methods
3. device::Client:::do_something() creates a message and sends it down the pipe
4. device::Server receives the message and calls some of the back-end methods
5. the back-end actually executes them

You can see there are 5 layers of execution... While we certainly need abstraction, we'd be fine with just 2 - 3 layers. I propose to remove device::Client methods in favor of render just sending messages directly. We can also remove the render::Client in favor of pure messages.

(+) less code for us to maintain, less layers to loose yourself in
(+) exposing asynchronous nature actually allows to benefit from it, i.e. send a bunch of commands and then receive some (instead of send-receive cycles)
(-) less convenient for the client (the problem does not apply to device <-> render interaction)

[kvark]

One negative aspect of the current system is that some logic is happening in Server update loops (both render::Server and device::Server), inside the match arms of the loop. That is in contrast with the plain pass-through logic that we do in separate methods of *::Client.

[brendanzab]

I agree that the current way of doing things is easy to lose yourself in. Could you try to explain again what design would you prefer? I didn't quite understand what you meant.

[kvark]

I'd prefer us to get rid of both render::Client and device::Client in favor of direct message passing. So instead of that:

let h_vs = self.device.new_shader('v', vs);

We'd do something like this:

self.device.stream.send(device::CallNewShader('v', vs));
let h_vs = match self.device.stream.recv() {
 device::ReplyNewShader(name) => name,
 _ => fail("...")
};

I know, that might not be the hottest piece of code in the town, but at least it can do multiple requests before asking for results.

[kvark]

Casts are gonna be fine, but Calls syntax is a bit too heavy. I'll think if I can find a good solution that would still reduce the number of layers but would not complicate the syntax too much.

[kvark]

Reasons why we need to keep render::Client:

• we could have an alternative client that doesn't spawn the render task but has the same interface (for easy switching)
• it can instantly return new handles, which is required for Asynchronous interface for the client #21
• it is more convenient to deal with by the end-user, comparing to message passing
• it can accept generics, while channels need concrete types

[kvark]

Thus, since render::Client should live, and everything related to the device is supposed to be covered by #48, I'm closing this.

[kvark]

Solving #60 will help with layers.