memcached Digest, Vol 9, Issue 3
greg at corga.com
Mon Apr 4 12:09:21 PDT 2005
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.
>-----BEGIN PGP SIGNED MESSAGE-----
>| 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?
More information about the memcached