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.
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?
About the protocol reuse, I don't find the text-oriented protocol
really
attractive, and a simple binary protocol was easier for me to write
and
debug, so I did.
The text protocol is certainly difficult to get right, but it is
used constantly at pretty much every high-volume content site.
Our binary protocol is considerably easier to implement (while still
maintaining some of the desirable performance characteristics from
the text protocol).
Memcached client compatibility was never on my plans, as originally
only
TIPC was supported (after a while, it became trivial to add other
transport protocols, so the rest was implemented), and that would
imply
I had to follow memcached protocols and worry about compatibility, and
I'm not really interested in any of that.
Heh, of course not. Having such a dependency on your project to a
different project could lead to maintenance issues. However, the
protocols don't change much. If they did, the various implementation
authors would be annoyed.
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.
--
Dustin Sallings
