Paul Colomiets

> > Ensure that nothing is re-exported from edgedb-protocol, so that we can make breaking changes in latter without disturbing users > > I don't see how that's going to...

So the whole proposal looks sensible. Except few minor things: 1. Not sure about `QueryResult` name (especially if #40 fixed) 2. We don't support tuple arguments yet, so `QueryArg` for...

> One problem with abstracting over `Value` and `Queryable` is context dependent (de-)serialization. `Value` is context dependent (especially on the deserialization side). So far `Queryable` is not. > > Though...

I'll consider reserving name. But why publishing release that breaks every now and then is better than using `git` url for the same purpose? I know you can't publish on...

> Mainly I just think a series of rough prereleases would be nicer to work with than using the code straight from git. Yes I agree. But they have associated...

Published [0.2.0](https://docs.rs/edgedb-client/0.2.0/edgedb_client/) as the first step with no guarantees and a bunch of not implemented functionality.

Well, yes, it looks like ugly design artifact. I have mixed feeling, though: `Queryable` is meant to mean a high level thing, i.e. something that you can query from the...

Unfortunately I don't think Rust coherence rules will allow that for `QueryArg`. But we may implement a derive with a flag, something like this: ```rust #[derive(QueryArgs)] struct MyArgs

Yes, we don't have that derive macro yet. It's in the to do list.

I still think that keeping it in the install makes sense: 1. It's what you teach in tutorial: `edgedb server install`. `--help` will help you update installation. I would say...