I still don't see how to make this play well with security. Security
needs to go under the transport layer so that it is easy to add
encryption on the wire. If you go with HTTP, the only way that is
portable at all is to use HTTP over SSL. SSL is for when there aren't
shared keys and Kerberos provides those shared keys. SPNEGO is the
standard method of using Kerberos with HTTP and we are planning to use
that for the web UI's. But SPNEGO is very much the least painful of
the alternatives and I'd rather not force our RPC services into that
corner.
I also have serious doubts about performance, but that is hard to
answer until we have code to test. It is an interesting question how
much we depend on being able to answer queries out of order. There are
some parts of the code where overlapping requests from the same client
matter. In particular, the terasort scheduler uses threads to access
the namenode. That would stop providing any pipelining, which I
believe would be significant.
In short, I think that an HTTP transport is great for playing with,
but I don't think you can assume it will work as the primary transport.
-- Owen
