[whatwg] Workers feedback

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:


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