Re: Change #6

Greg Stein <gstein@lyra.org> writes:

 
> All right. Let me do this one more time.
>
> 1) if I only receive delta windows, then I can't know whether the
> Content-Type is application/octet-stream ("plain text") or
> application/vnd.svn-svndiff

As Karl said, why can't you:

  * add a field to svn_txdelta_window_t that indicates the content-type

  * make svn_txdelta_apply() generate window-consumers that understand
    this field

  * add a "content-type" argument to svn_txdelta() so it will produce
    a window stream in the format you like.

This is a tweak to the existing system... seems more elegant to me
than a total inversion of the interface.

>
> 3) I cannot enable "send plain text all the time"
>
> 4) I cannot choose a different diff format for the wire.
>

This tweak should allow you to accomplish your points #1, #3, and #4.

 
> 2) the delta window model is "push-to-editor". the network code works best
> with a "pull-from-source" model. in fact, we may not even get Neon to be
> able to work with the push model, except by buffering everything into
> memory first.

This is the only point that scares me. Yikes. Is this a real
roadblock?

I'm confused about this, because neon is acting as an HTTP client and
mod_dav_svn is acting as the HTTP server. Don't HTTP clients "push"
requests at servers, and servers respond? How could mod_dav_svn
possibly "pull" data from neon? That seems like a backwards HTTP
model to me. Maybe you can clarify.

    
> (this buffering in memory will be happening for M2, btw; don't go commit
> 100M files unless you can hold that in memory on your client)

Heh, this is happening anyway within the client *and* fs libraries too.
It will all be fixed, no worries. :)
Received on Sat Oct 21 14:36:26 2006