On Fri, Mar 30, 2001 at 09:29:38AM -0600, Ben Collins-Sussman wrote:
> 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.
ra_dav/commit.c is not the person who sets up the stream, so commit.c has no
way to set the field or to select the format.
Since the delta stream is done by the *driver*, there is nothing the
*editor* can do about it. That sucks.
>...
> > 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.
Sorry, see above.
> > 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?
Yes. There is no way to use Neon in a push mode. I create a temporary file
right now, and then let Neon pull from that file.
If we had a pull-style delta interface, then I could set up Neon to pull
from that delta stream.
For systems that want to stick with the push style, then we'd just have a
function like:
apply_delta(stream)
{
while (1) {
window = read_window_from_stream(stream)
if (window)
old_push_style_function(window)
}
}
IOW, a pull-style interface allows an editor to use either style, at its
convenience. A push-style at the API cannot be converted into a pull-style
unless you buffer or use two threads, a pipe, and IPC.
> 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.
Yes, the client pushes stuff up, but the logic in Neon is:
- start request
- do:
- read a block of data to send
- write the block to the network
- end request
The start/end request is a single function call. It pulls data from us as it
needs it, to send it over the wire.
Want to know something *really* weird? mod_dav_svn *does* pull data from
Neon. Time to put on your heavy-duty thinking cap here:
Within Apache, when handling the data from a PUT, we read data from the
network, and throw it at the FS (in a loop). On the client side, it pushes
data over the network, at Apache. Here is the trick: when the client
writes to the network, it might *block*. What happens is that the TCP
stack on the Apache side becomes "full" if Apache doesn't read the data
(at all, or fast enough). This "fullness" is sent by the magic of TCP back
to the client side. When it is full, the client will block, waiting for
the server to signal that it is no longer full. The client then resumes.
In effect, mod_dav_svn reads from the network, which then signals Neon to
write more to the network.
mod_dav_svn pulls from Neon.
:-)
> > (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. :)
I buffer to disk now. Couldn't do it to memory.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Received on Sat Oct 21 14:36:26 2006