C. Michael Pilato wrote on Thu, Aug 04, 2011 at 10:57:46 -0400: > On 08/03/2011 10:40 AM, Daniel Shahaf wrote: > > cmpil...@apache.org wrote on Wed, Aug 03, 2011 at 14:00:39 -0000: > >> + (As an aside, Serf's potential as a platform for future > >> + improvement remains unproven and doubtful. For example, HTTPv2 > >> + removes canonical resource URLs, which works against the caching > >> + proxy concept that seems to be the strongest argument in favor of > >> + Serf's approach. But that's not strictly germane here.) > > > > That sounds odd for caching not to be taken into consideration in > > HTTPv2's design. And glancing at the httpv2 design notes suggests that > > it was explicitly a goal. > > > > Are you saying that somehow HTTPv2 actually made the cacheability > > situation worse in some cases? Or just that it doesn't make the > > situation as as good as it promised to? > > As I dig into this a bit, I realize that the situation isn't quite as bad as > I originally thought. But that's only because of a coding oversight on my > part. (Happy accident?) I'll explain below. Note that I'm assuming that > cacheability works best when the RA layers use a single canonical URL to > fetch a given resource. > > Let's first talk about the cost of addressing any particular server > node@revision resource. In HTTPv1, clients couldn't just calculate the URL > of a resource -- they had to negotiate with the server using WebDAV/DeltaV > abstractions. Multiple roundtrips per calculation ... performance shutdown > ... you get the picture. mod_dav_svn helps here by transmitting in its > update-style REPORT responses a "version resource URL", which the client > caches via the davprops store in the working copy to avoid future costly > lookups. HTTPv2 facilitates client-side construction of resource URLs > without server negotiation, therefore has no need of the davprops persistent > cache mechanism, and as such the code doesn't use the davprops stuff at all > when HTTPv2 is active. > > The second factor of interest here is the canonical URL issue. If I have a > file that was created in revision 1 and remains unchanged henceforward, a > client can address that file via any number of URLs. After all, file@1 == > file@2 == file@3 == ..., right? mod_dav_svn again tries to help here by > normalizing the version resource URL that it sends to the client for a given > resource based on the created-path and created-rev of the resource. So no > matter which version of our file we're talking about, mod_dav_svn will > report its versioned resource URL as: > > .../!svn/ver/<CREATED-REV>/<CREATED-PATH> > > Here's where I think the current code falls short. While the update process > still pays attention to the canonical version resource URL transmitted by > the server (that was the happy accident ... ra_serf *could* be ignoring that > today in favor of self-constructed URLs), that URL isn't cached in the WC > any longer. This means that future (non-update-style) operations performed > by the client will be addressing the resources by some self-constructed, > probably-non-canonical URL. Stuff still works, of course, but this eats at > the cache-friendliness. > > Does that help to explain things better? >
Yes; the problem is that some client-initiated requests do not canonicalize a node's identification to its created-path@created-rev, and consequently some[1] opportunities for caching are missed. <handwaving>I suppose that could be remedied --- eg, if the wc started caching those created-* coordinates.</handwaving> Thanks for the explanation, Daniel [1] Not sure what fraction of opportunities that 'some' is. > -- C-Mike > > [SIDEBAR: It just occurred to me that the server is still transmitting > HTTPv1-style version resource URLs, not HTTPv2-style URLs ... I guess that's > a separate issue, though.] > > -- > C. Michael Pilato <cmpil...@collab.net> > CollabNet <> www.collab.net <> Distributed Development On Demand >
