I¹ve pitched this idea before and I¹ll bring it up again because I think
it¹s swell and this might just be the thin-edge-of-the-wedge I need to
convince everyone else of the same.
I think we should have a reserved namespace for memcached config data for
critical metatdata like
version
stats
ports (ascii and binary)
you-name-it
We could dispense with commands like version and stats in favor of gets of
reserved keys. I.e.
get __stats__.pid\r\n
get __protocol__.ascii.tcp.port\r\n
get __version__\r\n
&c
I think this is much nicer way to deal with future protocols (or future
anything else) than having to code up a lot of auto-detection logic now that
is only additional overhead for existing implementations and invariably
not-quite-right for the new protocol that people actually find they want to
use some months or years down the line.
On 3/1/08 6:13 AM, "Brian Aker" <[EMAIL PROTECTED]> wrote:
> Hi!
>
> You know, I don't really need to have protocol auto-negotiation. In
> fact... I think it will just make the code a bit more obscure.
>
> What do I want?
>
> A way to know where memcached is listening for binary. For UDP I have
> the server now just defaulting to the same port as the TCP server.
> This makes it easy.
>
> To me the binary protocol is just an out of band protocol. I am going
> to be using it along side the text based protocol and just optimize
> around which works best at any point.
>
> The problem is... how do I find it?
>
> This is not a problem so much from the stand point of the developer,
> but from the stand point of the user.
>
> Keep things simple. The more someone has to learn about memcached (or
> in my case libmemcached) the more they are not working on what they
> really care about.
>
> Which is their own application!
>
> Lets keep this simple, lets find a way to keep both the code clean,
> and... lets find a way to let clients know "automagically" how to do
> things.
>
> So what do I propose? On connect the server send the client a packet
> which can be read in one read.
>
> Tell me:
> 1) Is UDP on.
> 2) Version
> 3) Port for binary protocol
> 4) Cache implementation.
> 5) Total Cache size.
>
> etc...
>
> Cheers,
> -Brian
>
>
>
> On Feb 29, 2008, at 9:56 AM, Dustin Sallings wrote:
>
>> >
>> > On Feb 28, 2008, at 19:56, Aaron Stone wrote:
>> >
>>> >> +1 for keeping things on the same port because we have a magic byte
>>> >> to
>>> >> differentiate protocols and to know when our server doesn't
>>> >> understand
>>> >> the client's version, too!
>> >
>> >
>> > Alright, since it keeps coming up, I branched on the train this
>> > morning and started to do protocol autonegotiation. It *almost*
>> > works, but one of my client tests is failing.
>> >
>> > --
>> > Dustin Sallings
>> >
>
> --
> _______________________________________________________
> Brian "Krow" Aker, brian at tangent.org
> Seattle, Washington
> http://krow.net/ <-- Me
> http://tangent.org/ <-- Software
> http://exploitseattle.com/ <-- Fun
> _______________________________________________________
> You can't grep a dead tree.
>
>