Provide a response to a comm?

[greglearns]

This is an exciting project.

Using a (possibly custom) HTTP Transport, if I have 2 locations: Client and Server, I'd love to be able to op.comm(Client, Server, msg) but then have the Server be able to give a standard HTTP response that the Client receives. Instead, it appears that the server has to broadcast or op.comm(Server, Client, ...), which would not be possible if the Client is not addressable directly (i.e. the Server can only provide a response to the initial HTTP request from the Client). I wanted to make sure I wasn't missing something, since this does not appear to be possible.

Thank you! And, your project is such a great idea!

[shumbo]

@greglearns

Thank you for starting this discussion, and sorry for the late response.

I understand your motivation, and it may be possible to implement something similar using a custom HTTP transport. My biggest concern is that choreography can express communication patterns that don't fit into the request-response pattern.

For example, it is legal for the server to send something to the client (without waiting for the client to initiate the protocol)

op.comm(Server, Client, x);

or the client initiates a request, but the server may respond with multiple responses.

op.comm(Client, Server, request);
op.comm(Server, Client, response_part_1);
op.comm(Server, Client, response_part_2);

We can write a custom HTTP transport that uses responses if we assume all the communications in choreographies will be paired with a response, but nothing prevents users from writing choreographies that don't fit into that category.

While it is out of the scope of this project, I will mention that multitier programming might be a good fit for client/server, request/response settings. Many multitier languages use function as a unit to specify where the computation should happen, so you can say, "execute the function f on the server." I think it works nicely with your case, as a request (function invocation) is guaranteed to be matched with a response (return value).

[greglearns]

Thanks for the explanation! That was helpful.

On Mon, Jul 15, 2024 at 6:01 PM Shun Kashiwa @.***> wrote:

@greglearns https://github.com/greglearns

Thank you for starting this discussion, and sorry for the late response.

I understand your motivation, and it may be possible to implement something similar using a custom HTTP transport. My biggest concern is that choreography can express communication patterns that don't fit into the request-response pattern.

For example, it is legal for the server to send something to the client (without waiting for the client to initiate the protocol)

op.comm(Server, Client, x);

or the client initiates a request, but the server may respond with multiple responses.

op.comm(Client, Server, request); op.comm(Server, Client, response_part_1); op.comm(Server, Client, response_part_2);

We can write a custom HTTP transport that uses responses if we assume all the communications in choreographies will be paired with a response, but nothing prevents users from writing choreographies that don't fit into that category.

While it is out of the scope of this project, I will mention that multitier programming https://en.wikipedia.org/wiki/Multitier_programming might be a good fit for client/server, request/response settings. Many multitier languages use function as a unit to specify where the computation should happen, so you can say, "execute the function f on the server." I think it works nicely with your case, as a request (function invocation) is guaranteed to be matched with a response (return value).

— Reply to this email directly, view it on GitHub https://github.com/lsd-ucsc/ChoRus/issues/27#issuecomment-2229663044, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABFXGOVX5TJNBFG3YF2R64LZMRPELAVCNFSM6AAAAABKHXZ5FWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRZGY3DGMBUGQ . You are receiving this because you were mentioned.Message ID: @.***>

[shumbo]

I'm closing this issue for now, but please feel free to reopen it or create a new one if you have additional questions!