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.)
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?)
Unless I'm missing something, there's simply no way to make that work
as properties are fetched just like files in WebDAV. (ra_serf does
ensure that properties get handled before the textdeltas.)
> Greg Hudson pointed you to ra_svn's pipelining design, which IIUC
> is somewhat async though not parallel?
ra_svn only does pipelining - so it doesn't have to worry about
receiving responses in any order, so it's easy to fulfill a
depth-first requirement.
So, no, I don't see any possible design pattern that I could use here
and honor all of the constraints without serializing (and adding
massive latency) to a significant portion of the update drive.
> 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.
> 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.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-11-14 17:39:38 CET