On 3/25/10 5:50 PM, Ian Hickson wrote:
What would the use case be for the second one? As far as I'm aware there's
only one use case here: making it possible to saturate the network but not
over-saturate it (i.e. to send data at the exact rate that the network can
take it, without getting behind by sending more data than the network can
handle, and without sending so little that the network is ever idle).
In practice, with real networks whose speed varies second-to-second,
this is not really feasible.
And given the various levels of buffering in a typical network stack,
I'm not quite sure how you see this working from the JS app's point of
view. Or is bufferedAmount reporting the amount of data that the server
has not yet acknowledged receipt of or something? The draft I'm looking
at doesn't say anything like that, but maybe it's out of date?
That's not even worrying about issues like the network becoming "idle"
while you're waiting for your process's time slice or whatnot.
I don't see a problem with defining this. I agree that if we include
overhead that it should be defined, but just saying that it's "the number
of bytes to be sent that have not yet been sent to the network" does
define it, as far as I can tell.
I'm still not quite sure why the "number of bytes" would include the
websocket framing bytes but not the SSL bytes, the IP bytes, the
ethernet frame, the Tor stuff when that's in use, etc. What makes them
special in terms of the protocol consumer needing to know about them (I
realize they're special in that we're defining the web socket protocol)?
This isn't a rhetorical question, to be clear; I genuinely don't see a
difference....
Whether it includes the overhead or not is mostly academic for authors, I
think. It's only relative numbers that actually matter.
Indeed.
I think viewing the API spec and the protocol spec as separate is a
mistake. They are one document:
Hold on. There doesn't have to be a tight coupling between API and
protocol here, as far as I can see. The API just deals with messages.
It seems pretty protocol-agnostic to me (and in particular, it seems to
me like the protocol can evolve without changing the API).
Is there a good reason to actually couple them?
It seems that the consensus is now leaning towards changing the spec again
to include the overhead
It is?
but I haven't changed it yet because I don't want
to be flip-flopping back and forth -- if we change this, I don't want to
change it back. I think the use cases I know of are addressed whether we
include overhead or not
Seems that way to me.
Given that, do we in fact need byte-exact values here at all? For
example, could we make reporting it whichever way conforming as long as
it satisfies certain criteria (monotonicity, etc)?
This is one of those cases (and I don't say this often!) when I actually
happen to think that overspecifying (in either direction) precludes or
over-complicates some perfectly valid and reasonable implementation
strategies, and since in practice the values returned don't matter much
I'd prefer to not thus overspecify.
-Boris
