Re: Flushes in httpd was Re: timeout mysteries SOLVED! (was Re: Large Repositories)

At 2:26 AM -0700 7/15/03, Justin Erenkrantz wrote:
>Either ap_filter_flush is a valid solution, or it should be removed
>entirely. You can't have it both ways. Requiring the addition of
>custom threshold code to *every* filter is a cumbersome requirement.
>If you really feel that's needed, then we should remove flush
>support to compensate. -- justin

Well, it might be that this, in turn, is a tad overboard. The
established conventions for network protocols are pretty highly
optimized and nuanced, with clear and unremovable roles for all these
pieces. Transports should certainly deliver data; they're encouraged
to batch the delivery for efficiency, but they're also responsible to
send the data sooner or later. Clients, on the other hand, should
not have to think about line discipline for the most part, but there
are occasions when this is necessary.

In this case, it sounds like there's a fundamentally message-based
service layer, waiting for its packet to be delivered and a response
to arrive, but using a fundamentally stream-based transport (which is
still waiting for enough data to make the send worthwhile). Do I
read that right? If so, that kind of core-algorithm mismatch is one
of the reasons for flush calls in the APIs.

-- 
-==-
Jack Repenning
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
o: 650.228.2562
c: 408.835-8090
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org