[whatwg] Workers feedback
ian at hixie.ch
Wed Jun 8 15:01:26 PDT 2011
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.
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
> >> 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
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
> 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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg