Justin Erenkrantz wrote:
> On Wed, May 28, 2008 at 11:57 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> I assume you mean, "the drawback and penalty of using ra_neon today".
>> ra_serf doesn't win here on any particular design merits -- it just
>> implements a propfind cache of the same variety that ra_neon could (and
>> should), too, right?
>
> I don't think it'd be feasible to implement a similar cache at the
> ra_neon layer as Neon hides too much of the underlying WebDAV
> interactions to just plug in a true property cache. So, it'd only be
> partially effective at best and be a nightmare to hook in, IMO. You'd
> probably need to rewrite large chunks of neon to do it right. --
You think? You know we don't use ne_propfind*, right? We've implemented
our own PROPFIND request parsing. So, is there something more to do than
just choosing the right keys for a cache of the results? We'd need
something like the URL, depth, and requested_props (or maybe we just always
request allprops and trust that the cache will offset the costs).
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-05-28 22:09:06 CEST