I get why you may strike out on your own and write an extension to memcached that does exactly what you want (kind of, there _are_ better tools, as mentioned), that's precisely what open source is about. I do not get why you're so persistent about getting changes that the community and maintainers have said several times is not the direction memcached is headed committed to the trunk. As Dustin just said, write your own engine. Put it on Github, show it off here, publicize it, write blogs about it, that's totally great! What's wrong with that?
- Marc On Fri, Feb 4, 2011 at 9:30 AM, Roberto Spadim <robe...@spadim.com.br> wrote: > i can´t replace PIC, i have more 2.000 unit of PIC here (a lot of > money), after that i can use arm with linux > for now i can just use PIC > ok, no help from forum, i will try to code by my self, if code looks > good could i send to memcache mail list and try to make it 'default' > in source code? > > > 2011/2/4 Dustin <dsalli...@gmail.com>: >> >> On Feb 4, 8:37 am, Roberto Spadim <robe...@spadim.com.br> wrote: >> >>> put at main memcache code, and we can port to others memcache forks, >>> got the quest? >> >> Our goals are quite far from this. It would be trivial for you to >> create an extension in the new engine branch to add lock support if >> you feel it solves your exact problem. You can do this today (right >> now!) without even reading the server code. It can be misuse of >> memcached, but it can be misused of memcached contained within your >> environment. >> >>> easy? with it i can have 3 or more send/receive removed from my >>> pic18f4550 code (save a lot of rom for me) >> >> Are you sure you're not looking for a job server (gearmand, >> beanstalkd, etc...)? Perhaps your mistake is in doing any of the >> processing on your PIC. > > > > -- > Roberto Spadim > Spadim Technology / SPAEmpresarial >
