Reconcile the W3C compliant WebSocket interface in dart:io with the one in dart:html

[sgjesse]

When the WebSocket interface in dart:html has stabilized the one in dart:io should be updated to match as closely as possible to enable the same client code to run both in the browser and in the standalone VM. Currently the following issues have been identified:

  * Add the WebSocketsEvents interface to dart:io for event registration
  * Review the event object naming
  * How about event properties which oes not make sense outside the browser?

[madsager]

Added this to the M1 milestone.

[sethladd]

Issue #3618 has been merged into this issue.

[madsager]

Removed this from the M1 milestone.

[DartBot]

This comment was originally written by jjinux...@google.com

---

Seth's comment in issue #3618 was pretty good, so I'm pasting it here. That'll also help for people searching for this bug:

Web sockets in dart:html:

  ws.on.open.add((e) {
    print("connected"):
  });

  ws.on.message.add((e) {
    print('received message ${e.data}');
  });

Web sockets in dart:io:

webSocketHandler.onOpen = (connection) {
  connection.onOpen = (message) {
    print(message);
  };
}

This difference leads to developer confusion. Why the difference? Should I emulate one or the other?

Let's unify the way callbacks are registered and handled across web sockets for HTML and IO. This is a specialization of the broader effort to create more unified looking libraries.

[sethladd]

We're close, with this new interface: http://api.dartlang.org/docs/bleeding_edge/dart_io/WebSocket.html

But, it's not exact.

[justinfagnani]

Even if the interfaces match, in order to be useful for something other than copy and paste, the implementations need to implement the same interface, otherwise code will likely fail in checked mode.

It might be good to create a dart:http library with interfaces that can be used in dart:io, dart:html, and in Apache (mod_dart uses it's own interfaces), App Engine, Elastic Beanstalk, etc.

[DartBot]

This comment was originally written by jjinux...@google.com

---

Why are we following a W3C interface meant for JavaScript in Dart? I thought the whole point of dart:html was to do things the Dart way. Once we figure out the Dart way, we should be consistent between dart:html and dart:io.

It seems to me that the Dart way is "socket.on.someEvent.add((e) => ...)".

[sgjesse]

The purpose of the WebSocket interface in adrt:io is to have an API in dart:io which resembles the one on dart:html so that the same code can be ported easily from the browser to dart:io. This is currently based on http://www.w3.org/TR/websockets/ (which does not mention JavaScript), but as dart:html is consolidated we will update this API to match it.

In general we are aiming at having both a simple API (like in dart:html) and a more advanced API with more control (like the current one in dart:io) for both web sockets and for HTTP client.

[justinfagnani]

It'd also be much better if code didn't have to be ported, but just ran on the browser and server without modification. For this, "resembling" isn't good enough.

Dart may be dynamic, but types are used frequently and checked mode is the default for development (and checked mode may end up being fast enough for production), so traditional dynamic language duck typing will often break.

This requires a common interface outside of either dart:io or dart:html that both WebSockets implement.

Then, the main entry point of a program can import the correct library for its environment, and create the WebSocket, or some factory function, and pass that to common code that actually uses the WebSocket. No porting required.

[sgjesse]

In the first version of dart:io we has a W3C like interface. With the dart:io v2 streams based interface we decided to not keep that.

If we want to have a common WebSocket API it should be a separate library which implements a common API on top of both dart:io and dart:html instead of trying to emulate the browser API in dart:io.

---

Added WontFix label.

[justinfagnani]

Why wouldn't we change the dart:html WebSockets API to match dart:io? Obviously the dart:html version needs to be updated to use Streams. When that happens, what reason is there for different APIs?

[sgjesse]

Of cause it will be an option to implement the dart:io API for the dart:html WebSocket. However there might be some obstacles here like

1. All dart:html APIs need to look the same in the way they expose events/streams
2. All dart:html APIs need to provide access to all features of the corresponding DOM class

which is why I suggested a separate API.

[DartBot]

This comment was originally written by @seaneagan

---

I believe it should separated from dart:html and dart:io into e.g. dart:web_socket, which works in all platforms (dartium, dart2js, command line), following the lead of dart:typed_data. Any functionalities not possible in the browser could be exposed via a subclass in dart:io.

[DartBot]

This comment was originally written by @MarkBennett

---

Is there any possibility to see this divergence between the dart:html and dart:io WebSocket implementation being resolved soon? I'm attempting to write shared WebSocket code between the client and server for the start project (lvivski/start#30) and am struggling with this inconsistency between the two APIs.

As Sean suggests, would it not make sense to have a common library outside of io or html which Dart applications could include, but which would be implemented differently in the separate environments?

The argument that the WebSocket implementation in dart:html should be consistent with other libraries in dart:html also highlights a compelling reason why it doesn't belong in dart:html, as unlike the rest of the code in dart:html, WebSocket exists in the VM and in dart2js.

Is there any chance this will be re-opened?

[sgjesse]

There are no current plans to create a library unifying the WebSocket interface between dart:io and dart:html. Currently Dart does not support libraries with different implementations for each environment.

For your application I suggest that you design your own WebSocket interface and than have two implementations in two different libraries.