C API

[Brian Aker]

On Fri, 2004-01-16 at 09:27, Brad Fitzpatrick wrote:
> /* gets a handle for a group of servers.  could set the servers here,
>    the domain, the time-out restrictions, etc.  like the Perl API.
>    also, perhaps a function pointer to the memory allocator, if not
>    malloc.  */

This sounds fine, except that if you lose one server, you end up losing
them all I would suspect (this is why I would really like to say that an
object is in a particular pool and just purge only that pool on a
failure).

So for a get you would say "key" from "pool" and upon failure return
nothing and tell all servers to purge "pool".

> /* for add/replace/set/delete: return boolean if "STORED" or "DELETED" */
> int memcached_VERB(memcached_client* mc, const char *key, ushort flags,
>                    time_t seconds, const char *data, size_t data_len);

Other then the change for "ushort" this is what mine did (the
memcached_get in mine calls an internal functions that takes as its
first parameter the verg (which is passed along by the calling method)).

> /* gets a single item, using mc's allocator, or nothing. */
> char* memcached_get(memcached_client* mc, const char *key);

See this wouldn't work for me. I have buffers to fill in MySQL and don't
want the library to allocate anything at all (no mallocs). Possibly have
the return value be a ptr to the position in the buffer that
memcahced_client. Could pass in a size_t that could be used to say how
much data is being returned. Still this solution wouldn't tell the user
how many times they would have to call memcached_get() to complete a
fetch.

Separate fetch sounds better since you can keep calling it until it
returns no data (and you can keep your buffers small).

Is there any advantage to making a get call with multiple keys?


> The "connect" stuff is an internal detail, not part of the public API.
> You don't make clients deal with that.  They just want to get/set and not
> know from where.

They need to know hosts and ports.

> Also, you'll want internal functions which return the non-blocking
> socket fds to wait on in your select loop.  (memcached should never assume
> a server is up or functioning quickly.  your select timeout is specified
> in *memcached_client.... something like a half second or a second at
> most.)

So a non-blocking cursor for a fetch method?


Is a boolean really good enough for error? If I go do an add I may want
to know why the failure occurred (aka was the object already there...
did I get a chunk error?).

   -Brian

-- 
_______________________________________________________
Brian "Krow" Aker, brian@tangent.org
Seattle, Washington
http://krow.net/
http://askbrian.org/
_______________________________________________________
You can't grep a dead tree.