- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 8 Jun 2011 22:01:26 +0000 (UTC)
On Fri, 4 Feb 2011, Glenn Maynard wrote: > On Fri, Feb 4, 2011 at 6:43 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > All workers should run soon, not maybe in the future. Not running a > > worker should be an unusual circumstance. Errors that occur in unusual > > circumstances aren't errors that authors will check for. > > > > This dicussion comes from Chrome having a very small limit currently. > > It is my understanding that this limit is temporary and not > > representative of what the API will be like once widely implemented. > > There will probably always be some limit, even if it's very high (eg. > 1024). Well certainly there comes a point where there are simply too many workers for it to make sense. > I think reasonable behavior when you exceed it is to throw an exception, > but the spec seems to disallow this. Maybe that's why Chrome has the > queueing behavior in the first place. Implementations are essentially allowed to do whatever they want in the face of hardware limitations like this; we refer to this as the hardware limitations clause: http://www.whatwg.org/specs/web-apps/current-work/complete.html#hardwareLimitations > >> Non-looping 0ms timers are common, to run code when the current call > >> finishes. > > > > Yeah, spec allows those fine. > > I should have said "non-recursive". That is, you can run a 0ms timer > from another timer without causing recursion, but you'll receive the 4ms > clamping unnecessarily. It might be possible to avoid this while still > preventing 0ms looping timers from busy looping, but the spec prohibits > that. (I could give an example of how this would happen, but I don't > think it's important enough to go into further for now.) What's the use case? On Sat, 5 Feb 2011, Samuel Ytterbrink wrote: > 2011/2/5 Ian Hickson <ian at hixie.ch> > > On Sat, 16 Oct 2010, Samuel Ytterbrink wrote: > > > > > > *What is the problem you are trying to solve?* > > > To create sophisticated single file webpages. > > > > That's maybe a bit vaguer than I was hoping for when asking the > > question. :-) > > > > Why does it have to be a single file? Would multipart MIME be > > acceptable? > > > > A single file is a solution, not a problem. What is the problem? > > Okey, I see the (implementation of the) web standards as the ultimate > framework. This makes it a great tool to create OS independent software > (if a browser is implementing the specs the same on both platforms). > Therefore its great if it supports as much of the usual behavior of > programs. I understand that this is a long process but.. almost every > thing is possible to inline with data-urls (wrote a simple script to do > this for me) but not web workers. And if you want to hand over a program > to a customer you want it to be 1 file, in many cases. These standards are intended for the Web. You don't have to hand anything over other than a URL. > The user case for my program is for a user that is a student that sits > at his/her schools computer. Having a DAISY book and needs to read it > with this app. The problem is: > > that the user are not allowed to install new software therefor can't > install a 'real' player. > > that the user cant play it online because a book is to large > > that the File API right now you cant get hold of a whole folder > structure. Ah. This isn't really a use case I think we should try to solve at the WHATWG. The WHATWG is specifically about improving the Web. > > > [...] trying to build a more optimal standalone DAISY player (would > > > be nice if i could rewrite it with web workers). > > > > Now that's a problem. :-) > > > > It seems like what you need is a package mechanism, not necessarily a > > way to run workers without an external script. > > if i understand you correctly you suggests a module system for > javascript? That would be nice but still web workers are needed fore > more then that. And you can do module systems with a macro-compiler with > out changing the specs. I just mean zip up all the files and give that to the user. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 8 June 2011 15:01:26 UTC