memcached Digest, Vol 9, Issue 3

[Greg Grothaus]

What is wrong with having the API just gain "added" functions(or default 
values for parameters depending on the API language).  Any calls to the 
old functions without a namespace identifier just automatically tack on 
some new default namespace to the call.  There is no state information 
between calls, things are still thread safe, etc.
-Greg

>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hi Brad
>
>| But now we go from everything inside memcached being O(1) to suddenly
>| having a potentially slow O(n) operation.
>|
>| The way I'd prefer to see this done is finish doing server-side namespace
>| support, then support a wipe on a namespace.
>
>I completly agree on that. O(n) is bad.
>
>I see two possible solutions for that:
>
>a) A major change in the API, because all requests have to add the
>namespace they are ment for.
>
>b) An additional command 'set_namespace'. Alle following commands in the
>~ current connection work within the given namespace until the next
>'set_namespace' is given.
>
>I think b) is the way to go. It does only add one additional command and
>does not change the current API. I think also that most of the time you
>have one namespace per connection. So the namespace can be set just
>after making the connection.
>Drawback: If you use multiple namespaces within one connection you have
>always to prepend the 'set_namespace'.
>
>What do you think?
>
>Cheers,
>Patrick
>  
>