On Thu, 2010-10-28 at 15:40 -0500, Eric Evans wrote: [ ... ]
> One solution to this is to implement a server-side query language, with > simple language drivers that manage all of the common functionality in a > consistent way (statement preparation, connection pooling, etc). > Library maintainers would then build their idiomatic interfaces on top > of these, (and I imagine, remove a metric crap-ton of code in the > process). [ ... ] > I've been chewing on all of this for a while so I'm brimming with ideas, > but I'll let the dust settle on this email before going any further. :) Since it looks like most people are receptive to the general idea, maybe I'll push my luck a little further by talking about implementation. What I've been bouncing around in my head is this: 1. Implement it in the Avro interface. 2. As new statements are added, mark the corresponding (avro) RPC methods as deprecated (or remove immediately). 3. When the query language has reached 100% feature coverage, the language specification transitions to 1.0, and <insert sane process TBD for change management>. 4. (Optionally )code our own transport and result serialization, and remove Avro as a dependency. 5. Profit. The rationale behind #1 and #2 is that the Avro interface is still considered experimental, nothing that goes on there directly impacts the supported API, and it has little to no existing user-base (that we know of). The existing parity with the Thrift interface means that the query language can be built out incrementally since holes in functionality can be plugged with the RPC methods. Ultimately I favor the complete elimination of the RPC methods because, well, as I've already stated I'm not a fan and so see no reason to maintain *two* forms for the duration. #3 is just about managing expectations. I don't favor anything overly bureaucratic; I do favor heavily engaging library maintainers. As for #4, this falls into the nice to have category, but at this stage in the game, we'd only be using a tiny fraction of what these frameworks provide. Creating our own wire protocol would allow us to shed a dependency and optimize for our specific use. Thoughts? -- Eric Evans eev...@rackspace.com
