Extensible command syntax

[Dustin Sallings]

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