Re: ra_serf violating editor API restrictions

Justin Erenkrantz wrote:
> On 8/9/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>> with this asynchronous, parallelized activity. But here's my real concern,
>> though: we have API rules and promises associated with them, and this
>> violation could cause problems for third-party consumers of the RA
>> interface. I don't think we should cavalierly disregard the API rules in
>> this fashion, even if there are performance benefits to be had. And I
>> suspect that we could still be getting most of these performance benefits
>> anyway without violating the editor rules.
>
> No, I don't think you can get the performance benefits without
> violating this particular rule. At the time, we looked at all of the
> implementations we had and all of our editors would not be affected by
> relaxing this constraint.
>
> The core issue is that we parallelize what files we checkout/update
> across a number of connections. In order to adhere to this particular
> constraint, we can't parallelize outside of a single directory at any
> given time as this editor rule requires that only one directory (and
> all children files) be open at a time.

I think you need to read the full text of the editor API. The editor
explicitly permits the concept of "post-fix textdeltas". This is a special
allowance that says that once a file baton is opened, you don't have to
close it until just before finishing the edit. In other words, the
following is allowed:

   open_root()
     add_directory('trunk')
       add_directory('trunk/foo')
         add_file('trunk/foo/file.c')
       close_directory()
       add_file('trunk/another_file.c')
     close_directory()
   close_directory()
   apply_textdelta(file.c's-baton)
   close_file(file.c's-baton)
   apply_textdelta(another_file.c's-baton)
   close_file(another_file.c's-baton)
   close_edit()

That means your primary connection can be doing a depth-first tree crawl,
quickly creating the skeletal tree structure. Your "other" connections can
be grabbing the files noticed in the primary stream and squirreling them
away into tempfiles (as textdelta data -- not decompressed). After the
directory crawl completes, you fly over the file batons and cram the
already-sitting-on-local-disk textdelta data through the apply_textdelta()
editor function, and close the files.

I agree it's less ideal performance-wise than the current setup. But API
rules are API rules are API rule. We either change the rules (which
requires, in my opinion, revving the editor interface and all associated
APIs), or we find a way to make ra_serf obey the rules. I perceive no other
options.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand