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

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

Closed
sgjesse opened this issue May 9, 2012 · 18 comments
Labels
area-library closed-not-planned Closed as we don't intend to take action on the reported issue library-io

Comments

@sgjesse
Copy link
Contributor

sgjesse commented May 9, 2012

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
Copy link
Contributor

madsager commented Jun 7, 2012

Added this to the M1 milestone.

@sethladd
Copy link
Contributor

Issue #3618 has been merged into this issue.

@madsager
Copy link
Contributor

madsager commented Sep 3, 2012

Removed this from the M1 milestone.

@DartBot
Copy link

DartBot commented Oct 26, 2012

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
Copy link
Contributor

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

But, it's not exact.

@justinfagnani
Copy link
Contributor

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
Copy link

DartBot commented Oct 27, 2012

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
Copy link
Contributor Author

sgjesse commented Oct 29, 2012

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
Copy link
Contributor

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
Copy link
Contributor Author

sgjesse commented Mar 5, 2013

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
Copy link
Contributor

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
Copy link
Contributor Author

sgjesse commented Mar 6, 2013

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
Copy link

DartBot commented Apr 1, 2013

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
Copy link

DartBot commented Jun 12, 2013

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
Copy link
Contributor Author

sgjesse commented Jun 12, 2013

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.

@sethladd
Copy link
Contributor

Agreed that a package should provide a higher-level library. However, it's challenging for end users to build libraries that work across dart:html and dart:io. We've always talked about pub managing this, but that functionality doesn't exist yet.

@DartBot
Copy link

DartBot commented Jun 12, 2013

This comment was originally written by @sethladd


For the record, you can create a single pub package with two libraries that share a common interface: https://github.com/sethladd/dart-shared-interface-example

This configurability could be improved, but hopefully this gets you on the right track. We'd love to see a pub package for a unified Web Socket interface :)

@kevmoo
Copy link
Member

kevmoo commented May 14, 2014

Removed Area-IO label.
Added Area-Library, Library-IO labels.

This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-library closed-not-planned Closed as we don't intend to take action on the reported issue library-io
Projects
None yet
Development

No branches or pull requests

6 participants