u1db-discuss team mailing list archive

[John Arbash Meinel <john@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On IRC we chatted a bit about trying to hook up the Go implementation
of U1DB to the python test suite runner. So I started experimenting to
hack something up.

I ended up digging into 'net/rpc'. Since we are driving this from
Python, I figured we didn't want to use GOB as the encoding, so I also
dug into 'net/rpc/jsonrpc'. It took a bit, because I was trying to do
the conversation over HTTP, but that isn't actually supported by the
system. (The rpc.HandleHTTP() functionality doesn't have a way to set
a custom codec for the conversations.)

To start with, I needed a 'main' package to run an actual service, and
in go you can't colocate packages. So we needed to change the
hierarchy somehow. I went with a separate package for the test service at:
  lp:~jameinel/gouda/gouda-test-serv

In doing that, I ran into the fact that go really wants you to use a
'package' name that matches the end of the official URL. So I put
together a rename from 'u1db' => 'gouda' for the package:
  lp:~jameinel/gouda/package-gouda

The idea is that if we name the package 'gouda' internally, then 3rd
party apps can:
 import "launchpad.net/gouda"
And 'go get' will figure out where to download the 'gouda' package and
build it and install it to the right location.

I'm not settled on that, but the launchpad.net/u1db URL is already
taken by the C/Python implementation. Anyway, it made it easier for me
to hack.

I then got the Go service to at least export a 'Create' method, and a
'Shutdown' method. And hooked up a python class that can start the
process, connect to the port it tells us about, and send/recv messages
to it.

Right now all the code is pretty synchronous, though we could slowly
push back and make it async. (jsonrpc uses a unique ID for each
message, so the responses can be distinguished. We might need to use
that if we want to do callbacks.)

At this point, I don't know how well we can use Go's Reflect to
trigger arbitrary requests on a Database object, and I don't think it
is very useful to write all of Database and then wrap all of Database
explicitly.

I'm interested in feedback, but I think this is a workable solution if
we want to use our large integration test suite against the developing
Go implementation.

John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlCGU/sACgkQJdeBCYSNAAMZKgCePY8ZYoyfJKyIm3wJtP3hU7dD
LxYAn0k8VbzIJv68TEBu5DnynAyJk6a4
=lC9O
-----END PGP SIGNATURE-----