On Wed, Feb 15, 2012 at 14:29, C. Michael Pilato <cmpilato_at_collab.net> wrote:
> On 02/14/2012 06:48 PM, Paul Burba wrote:
>> It seems we are far from any consensus on inheritable properties. The
>> major sticking points seem to be as follows:
>>
>> -- 1 -- Performance: Server Side (a.k.a. "Is this ultimately an
>> exercise in futility?")
>
> [...]
>
>> Looking at the server side, I might be oversimplifying, but I don't
>> see how this is a performance killer (full disclosure: I've only
>> looked at fsfs so maybe bdb is a problem).
>
> I don't see the problem here, either. The server-side search upward is a
> bounded operation, and should only really be required for clients examining
> the single chain of ancestor directories which exists above a given working
> copy's root directory.
When your reads become RPCs to a large-scale datastore (say, HBase,
Cassandra, Riak, etc) then every extra read "upward" becomes
expensive. The ideal is that you have a single RPC for each node
you're accessing. Not O(depth).
And please don't tell me that caching is the solution. That's a crutch
for a poor original design.
If you can limit that scan to *just* the relpath of the wcroot, then
maybe such a scan is workable as one FS request. IOW, as long as
inherited properties don't cause more reads when dealing with nodes.
But I fear that *will* be the case. Consider an update for subdir D.
You need to scan upwards from D to /, looking for changes in inherited
properties. Every single PROPFIND for D will need to perform that scan
because it is unclear on whether the client has all the correct parent
properties.
And thinking on that: how does the client do inheritance in a
mixed-revision working copy? D_at_10 inherits props from P, but the
client has P_at_5. If there are changes in P_at_7, then the inherited
properties a likely wrong for D_at_10.
>...
>> -- 5 -- Inheritance in the Working Copy
>>
>> There is still much to be determined re how inheritance works within
>> the working copy (see Julian's notes in the wiki), but I'm leaving
>> this as an open issue until the preceeding items are addressed.
>
> I suspect this will be the single largest point of contention, perhaps not
> so much in the desired behavior but in the recommended implementation. That
> said, +1 on deferring that conversation until the previous items have found
> consensus.
Yeah. Defer this. I'm not worried about the client implementation at
all. We have lots more cycles there. And we typically aren't making
RPCs for this (with the caveat of NFS drives :-P )
Cheers,
-g
Received on 2012-02-15 21:18:57 CET