Re: HTTP Frontend? (and a brief thought on materialized views)

On Thu, Mar 29, 2012 at 8:04 AM, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
1. I've been in discussion with some people about adding simple JSON extract
> functions. We already have some (i.e. xpath()) for XML.
>
> 2. You might find htsql <http://htsql.org/> interesting.

My colleagues and myself have thought about this quite a lot. Even
without changing any of FEBE's semantics (so far, I think they're
basically fine, with the glaring problem of hidden session state) I
think it may be a good time to experiment in supporting SPDY (clearly,
9.3+), which solves some of the problems of HTTP that make it pretty
unusable for interactive database workload.

For a long time, it looked like SPDY would become the IETF's HTTP 2.0.
But the future is still clouded, as just recently Microsoft
introduced their own mostly-compatible design. So that's a bit scary.

More concretely, here's what I really want. The first two concerns
are almost entirely technical, the latter two social, in that they
rely on notion of "common" or "standard':

* A standard frame extension format. For example, last I checked
Postgres-XC, it required snapshot information to be passed, and it'd
be nice that instead of having to hack the protocol that they could
attach an X-Snapshot-Info header, or whatever. This could also be a
nice way to pass out-of-band hint information of all sorts.

* Something similar to the HTTP "Host" header, so that one can route
to databases without having to conflate database identity with the
actual port being connected to. Yes, theoretically it can be done
with weird startup packet gyrations, but that is firmly in the "weird"
category.

* HTTP -- and *probably* its hypothetical progeny -- are more common
than FEBE packets, and a lot of incidental complexity of writing
routers is reduced by the commonality of routing HTTP traffic.

* Protocol compression -- but a bit of sand in the gears is *which*
compression -- for database workloads, the performance of zlib can be
a meaningful bottleneck.

Lastly, a case that can not as easily be fixed without some more
thinking is leveraging caching semantics of HTTP. think people would
really, really like that, if they could get away from having to
hand-roll their own cache regeneration in common cases.

--
fdr