Re: Change #6

On Thu, Mar 29, 2001 at 06:18:39PM -0600, Ben Collins-Sussman wrote:
> Greg Stein <gstein@lyra.org> writes:
> > My comment still stands: I can see a need/use for this change. The counter
> > point seems to be theoretical. So, what is the problem with doing the
> > change?
>
> It means a *whole* lot of rewriting -- lots of time and effort for
> little benefit. (Unless I underestimate how hard debugging is for
> you).

I'm not suggesting to do it now. That is exactly why I said that I'll find
a workaround in the mean time. But I am still going to continue to push for
this after M2.

And I've already outlined the "benefits" (in certain cases, "fixes").
Without the change, there are some things that I simply cannot do.

Lastly, just because rewriting is called for, does not mean it is improper.
Existence does not mean best/correct. Karl's got a phrase for this.

> Saying that "but we might be able to use sendfile() someday" is just
> as theoretical as saying "but we might break future editor
> compositions". Neither holds real weight. :)

Untrue. I am saying we can/will use sendfile. That is a specific use case.
Nobody has specified a use case of an editor composition that would read the
streams, so it remains theoretical.

[ and I could easily build a stream that provides for double-reading in any
  case. read N bytes into a buffer, return the buffer. next reader consumes
  the buffer. ]

> (And, as Karl pointed out, we can still make debugging easier for you
> by tweaking the existing system, rather than inventing a new system.
> This still isn't enough?)

It isn't just for debugging, but for actual operation.

If it was simply for debugging, then I wouldn't bring it up. I'd just slam
my system around locally and leave it at that.

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

   (IMO, sending svndiff over the wire for plain text does not follow the
    HTTP design well; we want to send the appropriate type, and be able to
    label it properly)

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 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)

3) I cannot enable "send plain text all the time"

4) I cannot choose a different diff format for the wire.

-g

-- 
Greg Stein, http://www.lyra.org/