Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Agree on wt.datagrams.outgoingMaxAge vs wt.datagrams.writable.maxAge #305

Closed
jan-ivar opened this issue Jul 6, 2021 · 5 comments
Closed
Labels
Discuss at next meeting Flags an issue to be discussed at the next WG working

Comments

@jan-ivar
Copy link
Member

jan-ivar commented Jul 6, 2021

#267 (comment) got merged with unfinished discussion. This is fine in the interest of iteration, but I think we need WG consensus on API. Here's what got merged, along with maxOutgoingSize which is being proposed in #301:

wt.datagrams.incomingMaxAge = 300;
wt.datagrams.incomingHighWaterMark = 20;
wt.datagrams.outgoingMaxAge = 800;
wt.datagrams.outgoingHighWaterMark = 10;
wt.datagrams.maxOutgoingSize = 1500;

Here's what I propose(d) instead:

wt.datagrams.readable.maxAge = 300;
wt.datagrams.readable.highWaterMark = 20;
wt.datagrams.writable.maxAge = 800;
wt.datagrams.writable.highWaterMark = 10;
wt.datagrams.writable.maxSize = 1500;

Organizing properties around natural objects we already expose seems cleaner and easier for web developers to understand, and seems better for encapsulation as well, versus relying on naming conventions to attempt to achieve the same correlation. In fact, having both seems discordant.

The argument that was raised against this was "avoid [subclassing] without a clear benefit". This seems like an implementation concern which would be lower on the priority of constituencies compared to web developer ergonomics.

@jan-ivar
Copy link
Member Author

jan-ivar commented Jul 6, 2021

"avoid [subclassing] without a clear benefit"

@ricea I'd like to understand the argument against subclassing, since we have existing examples of "[subclassing] without a clear benefit":

[Exposed=(Window,Worker), SecureContext]
interface SendStream : WritableStream /* of Uint8Array */ {
};

[Exposed=(Window,Worker), SecureContext]
interface ReceiveStream : ReadableStream /* of Uint8Array */ {
};

@ricea
Copy link
Contributor

ricea commented Jul 6, 2021

Yes, SendStream and ReceiveStream should be replaced with just WritableStream and ReadableStream now that they have no additional members.

Subclassing creates implementation complexity and technical debt through excessive coupling. This leads to implementations being inflexible and fragile, which ultimately hurts users by leading to an unstable and unpredictable platform.

There's also a real cost in terms of memory usage and startup time in adding more symbols to the global object. The cost for each individual symbol is small, but given the rate of evolution of the web platform the cumulative effect is large.

@jan-ivar jan-ivar added the Discuss at next meeting Flags an issue to be discussed at the next WG working label Jul 6, 2021
@yutakahirano yutakahirano added this to the Minimum viable ship milestone Jul 6, 2021
@yutakahirano
Copy link
Contributor

Filed #306 for SendStream and ReceiveStream.

@jan-ivar
Copy link
Member Author

Meeting

  • Revisit next meeting.
  • Group prefers no change, except rename to queueLength?
  • Do we pick incomingMaxAge or maxIncomingAge?
  • Do we pick outgoingMaxSize or maxOutgoingSize?

@jan-ivar
Copy link
Member Author

jan-ivar commented Aug 3, 2021

Closing for lack of interest.

@jan-ivar jan-ivar closed this as completed Aug 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Discuss at next meeting Flags an issue to be discussed at the next WG working
Projects
None yet
Development

No branches or pull requests

3 participants