common functionality of "dart:io" should work in Dartium

[sigmundch]

Currently using 'dart:io' in dart code that runs in dartium gives you an error of the form:

"Failed to load a file dart:io"

Long ago we added support for importing dart:io in dart2js so we can use the common part that is platform independent (e.g. Path).

Now we are hitting a similar issue in Dartium. We have a dartium extension that transitively imports dart:io. We don't expect all APIs to work, but basic path manipulation should work, path separators, etc.

[DartBot]

This comment was originally written by [email protected]

---

Maybe we should better spilt those parts from dart:io.

Thoughts?

---

cc @madsager.

[DartBot]

This comment was originally written by [email protected]

---

Added this to the Later milestone.
Removed Type-Defect label.
Added Type-Enhancement label.

[madsager]

We are still debating what to do with the Path class in dart:io. There are compelling arguments to remove the Path class and put some more functionality on URI for URI path manipulation. A separate library building on top of dart:io and dart:html can provide string based path manipulation. Bob has created the pathos library that does exactly that.

My feeling is that we would like to keep dart:io as a server-side library but that we should build libraries that bridge dart:io and dart:html. We should have an http, path, websocket, ... library that works whether you have dart:io or dart:html.

I'm not convinced that allowing import of dart:io in dartium is the way to go. It has a lot of stuff we cannot implement.

[munificent]

My feeling is that we would like to keep dart:io as a server-side library but that we should build libraries that bridge dart:io and dart:html. We should have an http, path, websocket, ... library that works whether you have dart:io or dart:html.

Agree completely. :)

The "dart:" libraries need to provide the most low-level, performant APIs possible because users cannot go any lower-level than those. But that often comes at the expense of usability for common simple cases. A layer of packages on top of the relevant "dart:" libraries gives us a way to have a higher-level (but perhaps not as performant or feature-rich) API while giving users the ability to opt out.

It also lets us evolve those APIs over time without forcing users to update their SDK (or, in the case of client-side code, wait for the entire world to update its SDK).

[sigmundch]

that sounds great - I agree that separating the high-level APIs into separate packages would be great, and having a generic path manipulation library that works everywhere would be ideal.

The 'pathos' library is almost there. It still needs access to a separator and the current directory from dart:io, maybe those small pieces of system information can be made available outside dart:io too (they would be patched differently in the vm vs dartium, etc)?

[DartBot]

This comment was originally written by [email protected]

---

what's the current directory in the case of Dartium?

[sigmundch]

Good question - I was asking that myself too. Maybe the baseUrl path from the initial request? Or maybe it can be provided by the developer?

I guess the issue here is that in dartium there are no paths, but uris. Maybe what we need is the functionality of pathos at the uri level too?

[munificent]

what's the current directory in the case of Dartium?

I haven't sat down to think through all of the corner cases, but my rough idea here was to use the current location's URL.

Maybe what we need is the functionality of pathos at the uri level too?

Pathos is architected around "path styles". Windows and POSIX are two different path styles, which is how it handles drive letters, network shares, separators, etc. My idea was to define a separate path style for URIs. I'm not sure if there are corners where that wouldn't make sense, but I think it might work.

[DartBot]

This comment was originally written by [email protected]

---

I assume consensus is we're not going to bring the whole dart:io into Dartium.

---

Added AsDesigned label.

[jmesserly]

Right, but the common subset should work. We're making progress on paths and typed arrays. Still to do:

• Files
• sockets/websockets
• httpclient/httprequest

This isn't a request for all of "dart:io" -- more that we need to harmonize dart:io and dart:html so libraries can be written that will work in browser or command line, as long as they stick to functionality that works in both places.

I switched to Area-Library, not sure if that's better. It's a crosscutting issue between dart:io and dart:html, as well as the language and what support (if any) we get for configuration specific libraries.

---

Removed Area-Dartium label.
Added Area-Library, Triaged labels.

[jmesserly]

Attempt to clarify bug subject.

The reason the blame is often placed on "import 'dart:io';" line -- if that line exists anywhere in transitive imports, even if the code is not used, it will prevent the app working in Dartium/browsers. It makes it far too easy for code to be coupled to the VM or browser.

---

Changed the title to: "common functionality of "dart:io" should work in Dartium".

[DartBot]

This comment was originally written by @seaneagan

---

This seems to be a duplicate of issue #1324, and there are specific bugs for http client (issue #2677), web socket (issue #2598), but not yet for file system APIs. Also, it should be targeted at dart2js as well, not just Dartium.

One downside of configuration specific libraries for these is then you still have to expose platform specific APIs in dart:html and dart:io, which means people will use them, and their code will not be portable. So wherever possible, following the example of dart:typed_data is best, by splitting the APIs out into separate libraries, e.g. dart:http_client, dart:web_socket, and dart:file_system. Then for platform specific functionality, could for example in dart:html (or possibly a dart:browser_http), add a BrowserHttpRequest (extends dart:http_client.Request) which adds support for CORS.

[DartBot]

This comment was originally written by @seaneagan

---

web socket bug is actually issue #2958

[kasperl]

Removed this from the Later milestone.
Added Oldschool-Milestone-Later label.

[kasperl]

Removed Oldschool-Milestone-Later label.

[floitschG]

Dartium has been removed from the repository.