This line was removed.
This word was removed. This word was added.
This line was added.
Changes (1)View Page History
h3. API Inputs
The view API inputs consist of feeding string data into an opaque parser context. The parser context will also be set up with callbacks which will be invoked upon receipt of each parsed view row, or on a parse error.
* Opaque parse context (API function to initialize/create this)
* Error callback
* Row callback
h3. API Output
* Row Callback
** Will contain a single row only
* Error Callback
** Will contain an error code, as well as the raw text for the response
* Parse context
** Will contain non-row meta-data returned in the view result, as well as any HTTP metadata (such as the return code)
h3. Usage Model
The usage model for the incremental row parsing is slightly more involved as it requires setting up two different callbacks. Generally speaking however, the receipt of each view row is to follow the semantics of responses for something like a multi-get, in that a new callback is invoked for each row.
One is required to create a "view row parser context" (which may be re-used) which allocates the necessary handles for the parser object. Then incoming data is fed into the buffer (a convenience HTTP callback may be provided to allow for this boilerplate to be performed transparently). When sufficient data has been fed and at least one row has been internally delimited by the parser, the row callback is invoked. If an error occurs during parsing, the error callback is invoked.
h3. Example Code
h2. Common Flag/Datatype handling
This may be a simple set of macros to set/unset flags
h2. C+\+ Wrappers
It might be prudent to also create proper C+\+ wrappers around libcouchbase, so that one may be able to do something like:
LCB::Result& result = lcb->get("foo");