go: echo app

go: echo app

This is an example go mojo application that can talk to
other mojo applications. The purpose of this is to have
an example of implementation that can be reused in writing
other go mojo applications. The boilerplate implementation
of mojo application interface will replace by its default
implementation that comes soon.

R=jamesr@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/dfd54eb4fbf6db49c0ed71ef59b3fc682c198b9d

[rogulenko, 2015-03-12 20:23:24]

Patchset #1 (id:1) has been deleted

[rogulenko, 2015-03-12 20:38:46]

rogulenko@google.com changed reviewers:
+ gauthamt@google.com

[rogulenko, 2015-03-12 21:01:36]

rogulenko@google.com changed reviewers:
+ jamesr@google.com

[jamesr, 2015-03-12 21:15:31]

jamesr@chromium.org changed reviewers:
+ jamesr@chromium.org

[jamesr, 2015-03-12 21:15:32]

These implementations are *almost* reusable in the NaCl bindings except for the
actual main() and acquiring the initial handle from CGo. Since the
implementation of those things only apply to the go.mobile impl, if we put them
in a main_android.go file will they only compile when GOOS=android? then we
could have a main_nacl.go that grabs the initial handle in the NaCl way and
reuse the rest.

https://codereview.chromium.org/1008543002/diff/20001/examples/BUILD.gn
File examples/BUILD.gn (right):

https://codereview.chromium.org/1008543002/diff/20001/examples/BUILD.gn#newco...
examples/BUILD.gn:46: "//examples/go",
test for mojo_use_go as well, or this'll break the android bot which doesn't
have the go toolchain stuff set up

https://codereview.chromium.org/1008543002/diff/20001/examples/go/echo_client.go
File examples/go/echo_client.go (right):

https://codereview.chromium.org/1008543002/diff/20001/examples/go/echo_client...
examples/go/echo_client.go:33: return err
what does returning an error here do? does this propagate back to the
stub.ServeRequest() call ?

https://codereview.chromium.org/1008543002/diff/20001/examples/go/echo_client...
examples/go/echo_client.go:44: if response != nil {
if response is nil we should consider that an error, no?

https://codereview.chromium.org/1008543002/diff/20001/examples/go/echo_client...
examples/go/echo_client.go:51: return nil
this should probably close out the service provider pipes here if they're
non-nil since this isn't going to use them

[jamesr, 2015-03-12 21:15:33]

These implementations are *almost* reusable in the NaCl bindings except for the
actual main() and acquiring the initial handle from CGo. Since the
implementation of those things only apply to the go.mobile impl, if we put them
in a main_android.go file will they only compile when GOOS=android? then we
could have a main_nacl.go that grabs the initial handle in the NaCl way and
reuse the rest.

[rogulenko, 2015-03-12 22:21:53]

On 2015/03/12 21:15:33, jamesr wrote:
> These implementations are *almost* reusable in the NaCl bindings except for
the
> actual main() and acquiring the initial handle from CGo. Since the
> implementation of those things only apply to the go.mobile impl, if we put
them
> in a main_android.go file will they only compile when GOOS=android? then we
> could have a main_nacl.go that grabs the initial handle in the NaCl way and
> reuse the rest.

Actually the build rule states what files to pick as main package and it looks
like if we want to have one android and one NaCl implementation we need to have
6 files (main_android.go, main_nacl.go and impl.go for client and for server).
The proper thing that we should do is implement application mojo interface that
automatically solves platform issues and I'm going to work on this next week.
The intention of this CL is to provide a temporary ad-hoc implementation that
you can copy-paste and modify locally in order to experiment/write sample apps.
I'm OK about not submitting this CL at all and just sharing it for testing
purposes,
but it looks like that submitting it is the best way to share it. Also I think
its
worth having a go mojo application that can talk to other mojo applications that
you can easily run somehow (for example, on an android emulator).

[rogulenko, 2015-03-12 22:22:03]

https://codereview.chromium.org/1008543002/diff/20001/examples/BUILD.gn
File examples/BUILD.gn (right):

https://codereview.chromium.org/1008543002/diff/20001/examples/BUILD.gn#newco...
examples/BUILD.gn:46: "//examples/go",
On 2015/03/12 21:15:32, jamesr wrote:
> test for mojo_use_go as well, or this'll break the android bot which doesn't
> have the go toolchain stuff set up

Added if (go_build_tool != "") as it is asserted in //mojo/go/rules.gni

https://codereview.chromium.org/1008543002/diff/20001/examples/go/echo_client.go
File examples/go/echo_client.go (right):

https://codereview.chromium.org/1008543002/diff/20001/examples/go/echo_client...
examples/go/echo_client.go:33: return err
On 2015/03/12 21:15:32, jamesr wrote:
> what does returning an error here do? does this propagate back to the
> stub.ServeRequest() call ?

Yes, this goes back to stub.ServeRequest() call.

https://codereview.chromium.org/1008543002/diff/20001/examples/go/echo_client...
examples/go/echo_client.go:44: if response != nil {
On 2015/03/12 21:15:32, jamesr wrote:
> if response is nil we should consider that an error, no?

Done.

https://codereview.chromium.org/1008543002/diff/20001/examples/go/echo_client...
examples/go/echo_client.go:51: return nil
On 2015/03/12 21:15:32, jamesr wrote:
> this should probably close out the service provider pipes here if they're
> non-nil since this isn't going to use them

Done.

[jamesr, 2015-03-12 22:24:43]

I think it's fine to submit this, just noting this as an issue to think about

[jamesr, 2015-03-12 22:26:06]

lgtm w/ one question

https://codereview.chromium.org/1008543002/diff/40001/examples/go/echo_client.go
File examples/go/echo_client.go (right):

https://codereview.chromium.org/1008543002/diff/40001/examples/go/echo_client...
examples/go/echo_client.go:49: fmt.Println(*response)
question: why does this fmt.Println()...

https://codereview.chromium.org/1008543002/diff/40001/examples/go/echo_server.go
File examples/go/echo_server.go (right):

https://codereview.chromium.org/1008543002/diff/40001/examples/go/echo_server...
examples/go/echo_server.go:29: log.Println(*inValue)
...but this one log.Println()s?

[rogulenko, 2015-03-12 22:34:37]

On 2015/03/12 22:26:06, jamesr wrote:
> lgtm w/ one question
> 
>
https://codereview.chromium.org/1008543002/diff/40001/examples/go/echo_client.go
> File examples/go/echo_client.go (right):
> 
>
https://codereview.chromium.org/1008543002/diff/40001/examples/go/echo_client...
> examples/go/echo_client.go:49: fmt.Println(*response)
> question: why does this fmt.Println()...
> 
>
https://codereview.chromium.org/1008543002/diff/40001/examples/go/echo_server.go
> File examples/go/echo_server.go (right):
> 
>
https://codereview.chromium.org/1008543002/diff/40001/examples/go/echo_server...
> examples/go/echo_server.go:29: log.Println(*inValue)
> ...but this one log.Println()s?

fmt.Println() is prefixed with I/GoStdio in android log, while log.Println() is
prefixed
with I/Go. My idea is that the only expected output from echo client and echo
server is
output of echo string on client side, while other output is for debug purposes
only.
So to filter only fmt.Println() you can write in shell:
adb logcat | grep "I/GoStdio"

[rogulenko, 2015-03-13 22:22:45]

Committed patchset #2 (id:40001) manually as
dfd54eb4fbf6db49c0ed71ef59b3fc682c198b9d (presubmit successful).