Timer should be accessible to web apps running in the browser

[DartBot]

This issue was originally filed by @seaneagan

---

There are currently two mechanisms for setting callbacks to run after a certain duration:

dart:html
  window.setTimeout
  window.setInterval
  window.clearTimeout
  window.clearInterval

dart:io
  Timer interface

This is unnecessary duplication. The dart:html versions should be removed, and the Timer interface should be moved alongside the StopWatch interface in dart:core.

[iposva-google]

I know this was discussed in the past. Matt, Jacob what was the resolution?

---

cc @jacob314.
Added Area-UI, Triaged labels.

[sigmundch]

I'll work on making Timer available in corelib, but I'll keep setTimeout around since it is expected to be there. We can decide about that later on.

---

Set owner to @sigmundch.
Added Accepted label.

[DartBot]

This comment was originally written by @seaneagan

---

Noticed the part about removing window.{set,clear}{Timeout,Interval} duplicates issue #757, so that part could be tracked there.

[sigmundch]

After we worked on a change to make Timer part of dart:core, we had more discussions about this and (I believe) we agreed to converge the io-related APIs in dart:html and dart:io, rather than moving things to dart:core.

We might require pub or some other mechanisms to support a transparent way of switching between browser and vm-based implementations of the API. The full solution is not clear to me yet.

I'm changing the status back to 'Triaged'...

---

cc @iposva-google.
cc @madsager.
Removed the owner.
Added Triaged label.

[DartBot]

This comment was originally written by @seaneagan

---

I found the code review for this:

https://chromiumcodereview.appspot.com/9692010/

It's unclear to me why the code was not committed. I saw it was suggested at one point to define the Timer interface in both dart:html and dart:io. That does not help. It would still be impossible to use the interface in code which needs to run transparently in both client and server, and I don't see how pub can help here, and even if it could, I think Timer is clearly a common enough use case that you shouldn't have to resort to any tricks.

If trying to not pollute dart:core's name space, then maybe create a dart:time library which has StropWatch, Clock, Timer, Date, Duration, and TimeZone, which could possibly be auto-imported with no prefix by default just like dart:core.

[munificent]

It would still be impossible to use the interface in code which needs to run transparently in both client and server, and I don't see how pub can help here

Our plan is that pub will support configuration-specific imports. So your code that needs to transparently use Timer would import something like:

#import('package:timer/timer.dart');

This Timer package can then provide multiple implementations that expose the same interface but internally use dart:io, or dart:html or whatever. When pub looks up that package for your app, it will select an appropriate implementation based on the environment that app runs in.

[DartBot]

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

---

Finer grained libraries + environment-specific implementations + ability for user-libraries to do the same would be so so awesome.

[sigmundch]

Exactly - the idea is not that Timer would be defined in both dart:html and dart:io, but that you'd be able to import 'package:timer' (for example) which would have different implementations depending on whether you are targeting the vm or the browser.

[DartBot]

This comment was originally written by @seaneagan

---

I see how pub can help an app which targets only the client OR the server, they can configure their timer package to point to the client or server version as needed. I don't see how it works though if your library/app targets the client AND the server, and uses Timer. I have already run into a similar issue with http requests, see:

http://dartbug.com/2677#c2

[munificent]

So what I described would work transitively across your dependency graph too. So your library would just import:

#import('package:timer/timer.dart');

which is platform-agnostic. That in turn means your library is platform agnostic. When some app comes along and directly or indirectly uses your app, only then and only in the context of that app will it select an appropriate concrete timer implementation and give it to your app. Concrete package resolution is always in the context of the top-level app and at that point you probably do know what environment(s) it will run on.

[DartBot]

This comment was originally written by @seaneagan

---

Thanks Bob!

Couple questions (for anyone):

Why expose window.{set|clear}{Timeout|Interval}, XmlHttpRequest, and other interfaces which duplicate core libraries such as dart:io at all? Why have two separate ways to do the same thing?

Doesn't it seem strange to have Stopwatch and Clock in dart:core, and Timer elsewhere?

How would packages expose client and server implementations? Presumably either by a package structure convention, or by path configuration in the pub spec file. Also, it seems there would be a need for "interface libraries" (and maybe even interface packages?) on which to base the client and server implementations, and for use by analysis engines.

Then "pub serve" and "pub deploy" and "dart2js" (called by pub) could use the convention or configuration to find the client implementations of packages. A Dart VM running on the server could similarly find server implementations of packages.

[whesse]

Issue #2851 has been merged into this issue.

[sethladd]

Any status on this? In this case, the Timer interface could be used in both server and client environments, enhancing the story of "writing Dart code that works in two places".

[DartBot]

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

---

Why does it take so long time? Since I asked for that ASAP in April (https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/6a396cf6305341c3#), my precision timer isolate application (https://gist.github.com/2652622) still needs external tick messages.

[sethladd]

Timer was moved into dart:isolate so I think we can close this issue. Please correct me if I'm wrong.

---

Added Fixed label.
Changed the title to: "Timer should be accessible to web apps running in the browser".

[sigmundch]

Unfortunately is not complete.

The interface moved to dart:isolate, but only the VM has the implementation available. We have to make the implementation for dart2js available too.

---

Set owner to @sigmundch.
Added Started label.

[sethladd]

Issue #4013 has been merged into this issue.

---

cc @rakudrama.
cc @vsmenon.

[sigmundch]

Fixed in r10460

---

Added Fixed label.