4 ms·
If you want quick adoption I would have your server also speak the memcached protocol on memcached's default port if it is all possible. You'll then have a ton
by dugmartin 17y ago
If you want quick adoption I would have your server also speak the memcached protocol on memcached's default port if it is all possible. You'll then have a ton of client libraries already written for you and the pain of testing and rollout is greatly reduced.
Very nice homepage btw.
Edited: added "also" between "server speak". I didn't mean you should dump your current API.
- Maro 17y agoWe originally had memcached support but discontinued it somewhere on the way. We think supporting the memcached protocol is confusing to our end-users, as there are strong differences between memcached and a consistently replicated (disk-persistent) key-value store. See for example my answer to the post below about safe and dirty reads. Also, we support a much richer set of commands than memcached. However, we are certainly going to bring back memcache protocol support if users demand it (the old memcache code is still in the source tree right now). Thanks.
- dugmartin 17y agoYeah, I could see where it could muddle your marketing message - you might end up looking like a "memcached clone" in people's mindset. However, I think if you positioned it right you could come across as a superset of memcached's features with the bonus of an easy migration for existing memcached users. Something like "we do memcached and so much more".
- Maro 17y agoYou're certainly right. One of the reasons we focused on an early release is to gauge user (client) interest. What's the level of interest in replication, consistent replication or distributed systems in general? Are people willing to use a newcomer's software? And so on.. Right now we have a few beta users, and are hoping to pick up new users with this release.