Create communication channel so Editor can talk to pub serve

[munificent]

To get the Editor hosting the pub dev server, it needs to be able to map from URIs coming from Dartium (which in turn come from the dev server) to file paths in the users workspace (and vice versa).

The Editor currently has its own implementation of that mapping. Since pub serve allows arbitrary transformations of files, it will have to ask pub for this. The basic idea is that the Editor can ask the running pub process "which file corresponds to this URI?" (and vice versa).

We can do this either as an HTTP API that the running pub process responds to (likely on a different port from the actual served app) or using stdin/stdout. I think the pub team is leaning towards HTTP, but we can do either.

[munificent]

Added this to the M8 milestone.

[nex3]

I'd like to hear more about what the URI mapping will be used for. This sort of mapping isn't necessarily straightforward -- for example, a JS file created by dart2js will have different sections that come from many different files. Barback can track information about the "primary" input (in the case of dart2js, this would be the entrypoint containing [main])... is that sufficient for the editor's use cases?

[keertip]

For starters, the URI mapping would be used to set breakpoints in Dartium. Take the case of user launching todomvc from the editor, sets breakpoint in todomvc-2/web/model.dart

launch url : http://127.0.0.1:3030/todomvc-2/web/index.html
breakpoint location: todomvc-2/web/model.dart:21
GET request is for : /todomvc-2/web/model.dart

and when stopped at breakpoint, script url sent to editor is http://127.0.0.1:3030/todomvc-2/web/model.dart

In the case of pub serve, the editor would ask pub to translate todomvc-2/web/model.dart to a location which dartium can understand when served by pub and on the pause ask pub to map it back to a url that editor could understand.

Does that make sense?

 

[nex3]

Yes, although setting breakpoints in the presence of transformers will require much more advanced capabilities than just a URL mapping.

[devoncarew]

We can do this either as an HTTP API that the running pub process responds to (likely on a different port from the actual served app) or using stdin/stdout.

I think another good option would be to use websockets. It's how we talk to Dartium. Essentially, the server that's also serving http traffic on port 1234 can act as a websocket server on the same port. So, no second port necessary, and we get a nice, structured protocol with push notifications.

That said, I'm not sure about the support for websocket servers in the dart:io library.

[munificent]

That said, I'm not sure about the support for websocket servers in the dart:io library.

I think Seth has experience there, I'll talk to him about it.

[devoncarew]

There's a bit more info here:

http://api.dartlang.org/docs/releases/latest/dart_io/WebSocketTransformer.html

Looks like it's supported.

[munificent]

Set owner to @munificent.
Added Started label.

[nex3]

I'm edgy about using WebSockets just because it's a new corner of dart:io that we haven't used yet, and historically those end up coming with a lot of pain.

[munificent]

Marked this as blocking #13935.

[munificent]

https://codereview.chromium.org/26634003/

---

Added Fixed label.

[DartBot]

This issue has been moved to dart-lang/pub#657.