Justin Erenkrantz wrote:
> On Fri, Nov 14, 2008 at 10:58 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> I pointed you to the editor's provision for so-called "postfix textdeltas"
>> (but I think you didn't like that the properties couldn't be similarly
>> handled).
>
> (FWIW, it's not a matter of "like", but rather "can't".)
>
> I vaguely remember that, but I never understood that suggestion as I
> believe that clearly violates ordering rule #5. As I've always read
> #5, you can't call close_directory with any open files left. So, I
> don't see how this suggestion could work without violating that.
> (There is no formal reference in the docs to 'postfix textdeltas' so
> I'm guessing that it's something that technically violates the
> ordering constraints but is tacitly approved.)
No, postfix textdeltas were part of the design of the editor, and date at
least as far back as my involvement in the project (when 'svn' was
"committing to" and "updating from" XML files).
> But, let's set aside #5 as you seem to think it's not important. But,
> ra_serf simply doesn't have the properties at open_file time - WebDAV
> requires a separate request to fetch them. If you could do:
>
> open_root
> ...open_dir
> ......open_file
> ...close_dir
> close_root
> for each file...
> change_file_prop
> apply_textdelta
> close_file
>
> That'd be easy to do. But, as I see it, a strict interpretation of
> this 'postfix textdelta' (whatever it might be) says it must be:
>
> open_root
> ...open_dir
> ......open_file
> ......change_file_prop
> ...close_dir
> close_root
> for each file...
> ...apply_textdelta
> ...close_file
>
> This requires that the properties are fetched serially and in order.
> The network pipeline would have to stall until *all* of the properties
> are fetched. Ugh.
>
> (What would be the ordering requirements for textdeltas? Can you
> interleave multiple apply_textdeltas to different files at once, or is
> that verboten? Do you have to process apply_textdelta/close_file in
> the order in which you opened them?)
Yep, I think you have the ordering diagrams correct, and a proper
understanding of the constraints with respect to properties. Now, the
editor API doesn't dictate that textdelta windows be done one-file-at-a-time
-- they are tied to a given file_baton, so maybe it doesn't matter what
order they appear in? I dunno. I think that was a scenario we failed to
anticipate when the editor was being solidified years ago.
>> That's true. I shouldn't have referred to Neon as the "one that works" --
>> that was not what I was trying to communicate. I was trying to express only
>> that Neon seems much faster than Serf in those messed-up server
>> configurations, and certainly no slower than itself elsewhere, so with Neon
>> as the baseline, we run the risk of a performance regression in some places.
>> By have both lines of code, we empower users to get the best deal for their
>> servers.
>
> No, but what you're missing that we're aiming to introduce a new
> protocol variant in 1.7 that will have a lot less latency. ra_neon
> simply won't ever get any of those benefits...so the ra_serf baseline
> should improve while ra_neon will be stuck in the past.
Well, yeah, ra_neon will be "stuck in the past" if nobody steps up to change
it to support the new protocol. And reasonably speaking, if the new
protocol demands parallelism, ra_neon won't go there.
>> OT: I almost hesitate to ask this, but is there value in implementing a
>> single-main-connection codepath in ra_serf that could be used when it
>> detects a server configured un-serf-friendly-like? We'd still be able to
>> drop Neon, but this would offer a best-of-both-worlds approach in a single
>> library?
>
> It would obviate the protocol benefits we're intending to get in 1.7.
... which will only be available for servers running 1.7, of course. :-)
>> Now might be a great time to rethink the editor API (it's too much and
>> too-pervasive code to want to rev it often), so if that's the recommended
>> solution to these woes, awesome!
>
> I don't think we would have to rev anything - just delete that
> constraint from the docs and we'd be done. =P -- justin
At the risk of your emoticon being partly serious, and for the benefit of
other readers of this thread, allow me to make something crystal clear:
You cannot relax this constraint while maintaining the promises
of the API.
There has already been one known written-to-spec editor that didn't work
over ra-serf due to the way that RA implementation was violating the API.
How many other third-party written-to-spec editor implementations also don't
work with ra_serf? We don't know. But by the very definition of the thing,
if a written-to-spec use of our APIs is forced to be modified in order to
continue working, we've broken the compatibility promises of that API.
There is no other interpretation to be had.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-11-14 18:55:54 CET