Resent to the correct list.
On 17.12.2012 11:41, Branko Čibej wrote:
> On 17.12.2012 11:25, Daniel Shahaf wrote:
>> stefan2_at_apache.org wrote on Mon, Nov 26, 2012 at 00:21:26 -0000:
>>> Author: stefan2
>>> Date: Mon Nov 26 00:21:26 2012
>>> New Revision: 1413451
>>>
>>> URL: http://svn.apache.org/viewvc?rev=1413451&view=rev
>>> Log:
>>> On the cache-server branch.
>>>
>>> * BRANCH-README: add
>>>
>>> Added:
>>> subversion/branches/cache-server/BRANCH-README
>>>
>>> Added: subversion/branches/cache-server/BRANCH-README
>>> URL: http://svn.apache.org/viewvc/subversion/branches/cache-server/BRANCH-README?rev=1413451&view=auto
>>> ==============================================================================
>>> --- subversion/branches/cache-server/BRANCH-README (added)
>>> +++ subversion/branches/cache-server/BRANCH-README Mon Nov 26 00:21:26 2012
>>> @@ -0,0 +1,109 @@
>>> +Goal
>>> +====
>>> +
>>> +Provide a stand-alone executable that will provide a svn_cache__t
>>> +implementation based on a single shared memory. The core data
>>> +structure and access logic can be taken from / shared with today's
>>> +membuffer cache. The latter shall remain available as it is now.
>> memcached solves the problem you're stating above, and it's an
>> independent third-party project. Your solution is specific to
>> Subversion (it's in libsvn_subr and is not in the public API). If
>> you're solving the same problem memcached does, why does your solution
>> need to be specific to svn? Should it be a standalone tool that
>> Subversion interfaces to as an optional dependency, and any other
>> memcached consumer can switch to too?
>>
>> I don't mean to discourage you from doing this work; I just wonder
>> whether the non-public parts of libsvn_subr is the right place for
>> it to live in.
> I've been wondering about all this caching, actually. There's memacache,
> as Daniel mentions, and there's redis, and a bunch of other caching
> solutions that have different strenghts and weaknesses. Yet here we are,
> reinventing the wheel (and if I read the mails on the topic correctly,
> having lots of fun while doing that).
>
> It would be much better if fsfs could be configured to use one of
> several caching servers and then the administrator would worry about the
> rest. I think it's perfectly fine to require one of them.
>
> I realize it's too late to do this for 1.8. But I doubt rolling our own
> cache server makes any kind of sense.
>
> -- Brane
>
Received on 2012-12-17 13:30:12 CET