Fri, 16 Jan 2004 10:09:36 -0800
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
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
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
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 "Krow" Aker, email@example.com
You can't grep a dead tree.