On Nov 7, 2007, at 11:29 , Tomash Brechko wrote:
What are your goals, out of curiosity? For review it'd be helpful to
know problems which are not solvable using the present protocol.
My short term goal is to implement new commands with extensible
param[=val] syntax. Then for update commands I'll add 'noreply'
boolean option (which will be truly optional, that's the point), and
will set it if user aren't going to use the reply anyway, for instance
when Perl binding is called in void context (wantarray returns undef).
Perhaps this will speed up things a bit. The idea is not mine
actually.
I don't feel that this answers the question. How are the current
commands insufficient for your needs? They seem to work pretty well
for most people.
I'm a bit dubious of the performance benefits of not responding in
general. We have the same sort of thing in the binary protocol for
doing bulk fetches, but there has to be something to tell you when
you're completely done. I don't see that you could process another
command afterwards without it.
Are you concerned about doing a large number of updates in a batch?
Are you sure you can't handle this on the client side? Pipelining
makes the responses become almost a non-issue.
On Wed, Nov 07, 2007 at 10:16:00 -0800, Dustin Sallings wrote:
Your proposal is incompatible with the binary protocol. Today, they
run on different ports.
I only showed that binary and text protocols could co-exist. Pity if
it was already made by incompatible means.
Others have brought up running different protocols on the same port.
It's somewhat possible (would require increasing the complexity of the
code somewhat), but I don't much see the point. A client shouldn't be
expected to discover what protocol a server speaks, so I'd expect
you'd have to configure it at least somewhat.
I don't see how you could go from a fixed format to an extensible
one without imposing overhead.
Of course there will be few more instructions, I don't count that as a
significant overhead. If we talk about extensible binary protocol,
recall how UTF-8 works: you have to process as many bytes as required
to encode the data, no more. So additional parameters could be
chained in the similar way. For text param[=val], you have to process
as much pairs as are there, and it's user's responsibility to give as
little of them as required.
This makes sense in abstract, but I'm failing to see the deficiency
you think warrants it.
--
Dustin Sallings
