An alternative to Tugela cache

Alberto Bertogli albertito at
Mon Sep 3 20:32:55 UTC 2007

On Sun, Sep 02, 2007 at 10:22:16PM -0700, Dustin Sallings wrote:
>  On Sep 2, 2007, at 15:32, Alberto Bertogli wrote:
> > The C library is quite simple, and writing bindings to it (instead of
> > re-writing it in a different language) should be close to trivial to
> > anyone familiar with the language in question (be it Perl, PHP,
> > whatever).
>  	Well, I'd argue that trivial is asking someone with a deployed application to reconfigure it to 
>  use your cache.  The further from that you get, the less trivial integration becomes.

Oh, I agree with you on that. I just don't expect people to do that
migration, because I think of nmdb as a different thing, so I'm not too
worried about deployed applications trying to move from memcached to

>  	Trying to get everyone to use your C library is certainly less trivial than you'd think.  It's 
>  very unlikely anyone running a java application or .net application would be willing to go through 
>  the work of linking in your unmanaged code.  If your code is synchronous, will it cause 
>  unmanageable blocking in, say, a twisted app when it's deployed?  If it's asynchronous, will it fit 
>  into my event loop?

Oh, I don't expect _everyone_ to use the C library, but I think using
bindings instead of rewriting when possible makes maintenance much
easier. Reimplementing it in another language is no big deal (it's less
than 1500 lines of C code at the moment, including comments).

About the synchronous operation, an extension to the API to allow
asynchronous use is on my TODO list, and I hope I can include it on the
next release.

>  	I'm just trying to point out that, IMO, that you would have an easier time finding adopters if it 
>  took them less work to incorporate your application into theirs.

I agree, if "incorporate" means just replacing memcached with nmdb. As
that is not something I expected people to do (well, some may want to
try it, and yes, it's going to be harder than just changing the server
for them), I chose to write a new protocol and new libraries, that
simplify maintenance and external dependencies a lot.

That said, I can take a look at implementing the memcached protocol on
the server side if there is enough need for such a thing in the future.
At this moment, I'm more interested in adding some features that nmdb
still needs (like stats, or asynchronous client operation), but it's
entirely possible given how nmdb is designed.

Thanks for all the suggestions!


More information about the memcached mailing list