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

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

Closed
sigmundch opened this issue Feb 20, 2013 · 16 comments
Closed

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

sigmundch opened this issue Feb 20, 2013 · 16 comments
Labels
area-library closed-obsolete Closed as the reported issue is no longer relevant P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug

Comments

@sigmundch
Copy link
Member

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

DartBot commented Mar 15, 2013

This comment was originally written by antonm@google.com


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

Thoughts?


cc @madsager.

@DartBot
Copy link

DartBot commented Mar 15, 2013

This comment was originally written by antonm@google.com


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

@madsager
Copy link
Contributor

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

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

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

DartBot commented Mar 15, 2013

This comment was originally written by antonm@google.com


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

@sigmundch
Copy link
Member Author

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

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

DartBot commented Mar 27, 2013

This comment was originally written by antonm@google.com


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


Added AsDesigned label.

@jmesserly
Copy link

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

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

DartBot commented Apr 1, 2013

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

DartBot commented Apr 1, 2013

This comment was originally written by @seaneagan


web socket bug is actually issue #2958

@kasperl
Copy link

kasperl commented Jul 10, 2014

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

@kasperl
Copy link

kasperl commented Aug 4, 2014

Removed Oldschool-Milestone-Later label.

@kevmoo kevmoo added P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug and removed triaged labels Feb 29, 2016
@lrhn lrhn added the core-m label Aug 11, 2017
@floitschG floitschG added closed-obsolete Closed as the reported issue is no longer relevant and removed core-m labels Aug 29, 2017
@floitschG
Copy link
Contributor

Dartium has been removed from the repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-library closed-obsolete Closed as the reported issue is no longer relevant P2 A bug or feature request we're likely to work on type-enhancement A request for a change that isn't a bug
Projects
None yet
Development

No branches or pull requests

9 participants