search

dart-lang / sdk

The Dart SDK, including the VM, JS and Wasm compilers, analysis, core libraries, and more.
https://dart.dev
BSD 3-Clause "New" or "Revised" License
10.25k stars 1.58k forks source link

client-side dart:io library #1324

Closed DartBot closed 9 years ago

DartBot commented 12 years ago

This issue was originally filed by @seaneagan

It would be nice to be able to use the existing server-side dart:io library on the client as well.

Instead of having the dart:html library include the HTML 5 File API directly, the dart:io library could be implemented in the client as wrappers for the HTML 5 API.

If certain operations are not supported by the HTML 5 File API, then an UnsupportedOperationException can be thrown when attempting to use them.

The client side Dart VM could fill in holes that are not available in the HTML 5 File API.

dgrove commented 12 years ago

Removed Type-Defect label. Added Type-Enhancement, Area-UI, Triaged labels.

DartBot commented 12 years ago

This comment was originally written by @seaneagan

Here is a more detailed look at which sub-libraries of "dart:io" (see http://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/runtime/bin) could exist in a Dart -> JS environment (web browser) along with their backing JS APIs. These JS APIs could all then be removed from from dart:html (since they are unrelated to HTML):

file, directory -> http://www.w3.org/TR/FileAPI/ input stream, output stream -> http://www.khronos.org/registry/typedarray/specs/latest/ httpclient -> https://developer.mozilla.org/en/XMLHttpRequest socket -> http://www.w3.org/TR/websockets/ platform -> http://closure-library.googlecode.com/svn/docs/closure_goog_useragent_useragent.js.html timer -> https://developer.mozilla.org/en/DOM/window.setTimeout

There are a few things which will be in "dart:io" will not make sense on the client, such as an HTTP server. To solve this, either only the smaller sub-libraries would be available in the client, instead of "dart:io" as a whole, or the server-only parts of "dart:io" would just throw UnsupportedOperationException or similar when used in the client.

DartBot commented 12 years ago

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

This would be incredibly useful for work I am doing on chromeos. If you want a subset could you just call it dart:clientio or dart:client or something? Either way, I hope it happens.

dgrove commented 11 years ago

Not sure where this will eventually belong, but it not in area-ui.

cc @blois. cc @madsager. Removed Area-UI label. Added Area-Library label.

blois commented 11 years ago

Even APIs such as HTTP server would be very cool to have working for Chrome Applications now that apps can accept socket connections.

DartBot commented 11 years ago

This comment was originally written by @financeCoding

yep, would be awesome! https://github.com/dart-gde/chrome.dart/blob/master/lib/src/socket.dart has very early support for socket but does not implement dart:io.

DartBot commented 11 years ago

This comment was originally written by oj...@quickrworld.com

"The Socket exposes both a Stream and a IOSink interface, making it ideal for using together with other Streams."

Would help if the implementation on the client side does the same; exposing a Stream interface would be most useful.

DartBot commented 9 years ago

This comment was originally written by beatg...@gmail.com

It's been over a year since this issue was opened and Dart has been in 1.x for over a year.

Is there any update on whether this is even on the radar for Dart?

justinfagnani commented 9 years ago

We have started a file system abstraction package, that can have implementations in different environments, including Chrome and possibly html5. No one's had time to work on it recently, but contributions should be easy to make.

It of course would require that all IO code be written against this package rather that dart:io, but once done that code would be portable across environments.

https://github.com/google/files.dart

DartBot commented 9 years ago

This comment was originally written by @stevenroose

An abstracted HTTP interface would be very beneficial as well.

I'd propose a (fictional) dart:http.HttpClient interface that both dart:io.HttpClient and package:browser_client.BrowserClient can implement.

It's very cumbersome that libraries that try to implement a protocol that is specified around HTTP has to worry about whether it is run in VM or a browser.

DartBot commented 9 years ago

This comment was originally written by @zoechi

This is what https://pub.dartlang.org/packages/http does.

sethladd commented 9 years ago

This isn't planned. Hopefully if/when Dart has configuration/platform configurable libraries, this can be built by the community.

jarrodcolburn commented 5 years ago

I'm interested in looking at this issue :) By compiling subset of dart's code to wasm.

Tools like Emscipten's emcc can compile c to wasm. Emcc has a file system api that adapts many of c's stdlib calls to webassembly, please see https://emscripten.org/docs/api_reference/Filesystem-API.html . Example, obscuring filesystem calls as IndexedDB.

Is there any chance that a subset of dart-lang c code can be compiled to wasm? Then used to make dart:io for web?

Does anyone think this is possible? I tried looking into this recently but am unfamiliar with the ninja build system, and want to get an opinion and recommendations on where to start thanks.