Introduce Send with callback or response functionality in go

[stefansavev-o]

The livescript send functionality supports a callback like this:

exoRelay = new ExoRelay exocom-host: host, exocom-port: port, role: role
exoRelay.send 'message.request {field1:..., field2:...}, (_, {outcome}) ->
  console.log "'message.response '#{outcome}'"

Introduce a similar functionality. I propose the following signature

func (e *ExoService) SendWait(message exorelay.MessageOptions, timeout time.Duration) (*structs.Message, error) {
// use the message id to pair the request to the response
// return the response, a timeout or a connection error
}

Proposed Usage:

    payload := make(map[string]interface{})
    payload["query_param_1"] = p1
    payload["query_param_2"] = p2
    msg := exorelay.MessageOptions{Name: "message.request", Payload: payload}
    replyMsg, err := exoservice.GetService().SendWait(msg, time.Duration(500*time.Millisecond))
    if err != nil {
        return nil, err
    }
        return replyMsg, nil

[charlierudolph]

Are you asking for that functionality in exorelay or exoservice? You point to exorelay in js but then want this implement in exoservice.

Also for the exoservice, there currently isn't an exposed send function. There is only send function passed to the message handlers. Is that where you would want this function?

[stefansavev-o]

In ExoService. I can add sample code with my solution if you are interested.

[charlierudolph]

Yeah that would be helpful

[charlierudolph]

Also one of my questions wasn't answered

Also for the exoservice, there currently isn't an exposed send function. There is only send function passed to the message handlers. Is that where you would want this function?

[stefansavev-o]

That will work for my use cases. but the flow is like this

onHandler(msg){ result := await call exosphere with another message (similar to NodeJs and Python await, although go does not have that) do something with result return from the handler }

[charlierudolph]

Okay cool. That should be easy enough to add

[stefansavev-o]

I encountered a dead lock when I implemented this and had to put the handler on a go routine. So deadlocks is something to watch for.

[charlierudolph]

@stefansavev-o a change @kevgo wants to make is removing responseTo and adding activityId where a message basically starts a thread which any service can reply to. We can introduce a WaitForMessage method that allows you to pass in an activityId and a message name to wait for a specific reply

[stefansavev-o]

ok, so it would be something like

activityId := Send(...)
response: = WaitFor(activityId, msgName)

Ok, this will be useful. If you generalize WaitFor to multiple activities/messages also very useful.

[charlierudolph]

blocked by #166