Hi!
On Apr 11, 2011, at 12:01 PM, Trond Norbye wrote:
> Intentionally, there is no significant difference in protocol over
> 1.4.x. There is one minor change, but it should be transparent to
> most users.
What is the change?
When doing a diff I could one change in an ENUM, and also the addition of
"touch" which has no description.
> Defining this now will allow us to start moving down the path to
> vbuckets in the default_engine and allow other engine implementors to
> consider vbuckets in their design.
Looking through the notes I don't see any discussion of what the format for
configuration is. When looking through what Dustin has it seems to be a
reference to some JSON which isn't documented. Also, is everyone expected now
to install CouchDB in order to use Memcached? That seems like a hefty
requirement.
> change in the server. It is solely up to the backing store to
> implement this, so it can make decisions about what resources are used
> to implement TAP. This functionality is commonly needed enough though
> that the core is aware of it, leaving specific implementation to
> engines.
Can this stream be documented? How about picking a name other then TAP so that
there is no confusion between this and "System Tap" which the Linux kernel
folks have.
> There are a few new commands available. The following sections
> provides a brief description of them. Please check protocol_binary.h
> for the implementation details.
There is just an ENUM in the file, that isn't enough for anyone who is perusing
the document. The original document Brad did is a good example of what should
be done.
> The touch command lets you set the expiry time for an object without
> retrieving the object. In most cases, you will not want to do this
> unless you provide a CAS value to ensure that you're touching the
> correct version of the object.
What happens if the object is not available? Is it possible that the server
will send an error back? What errors?
> 1.3.3 SET_VBUCKET, GET_VBUCKET, DEL_VBUCKET
> --------------------------------------------
>
> These commands are used to set, get or delete a vbucket on the server.
How should these commands be structured? What possible errors exist? Is there a
reference implementation?
> 2.1 Engines
> ============
> environment. People have different requirements for their server. Some
> people need ACID, others may prefer ecstacy ;-) The storage interface
How can you perform XA with this? If not, does this mean that each operation in
transactional? How is a conflict reported? If this is an ACID interface, what
is the isolation for events?
> 3.3 aggregate
> ==============
>
> The combination of the storage engine interface and the SASL auth
> allows for the combination of a connection-based stats. The aggregate
> subcommand is used to aggregate the stats from all of the connections
> on the server. The stats returned from the aggregate subcommand is the
> same as the normal stats command.
Are all of the stats being updated so that users can see it? How is this being
performed in a backwards compatible way?
Its great to see work being done, but we need a lot more information to support
this.
Alan has commented, and from a quick run through it looks like top keys cuts
performance in half. Is this going to be solved before a GA release?
Cheers,
-Brian
