Re: Workers

Justin James wrote:
>> The WindowWorker object isn't how you execute code, it's just the
>> global
>> object. Whatever mechanism we use, we have to have a global object.
>>     
>
> Yeah, I later figured this out. This draft is *really* difficult to follow,
> and reading the thread with Andrew, I am not the only one who is having a
> hard time reading it. I can't really put my finger on it, but it feels more
> like the summary of a conversation between a group of people who already
> intimately know the subject and just need to have it on paper than an actual
> spec. I know, that's why it's a draft and not the final form. :)
>
>   
I think this something about how this document is styled.
It appears as too many different emphasizing styles are used. Christmas 
tree style I would say.
Try to find something particular on that tree...

Usually people reading text by paragraphs not by separate words so it is 
difficult to catch
meaning if text is obscured by various colors and decorations.
>> As far as I can tell, data: URLs of megabytes in length work fine in
>> all
>> major shipping browsers that support data: URLs. Can you give an
>> example
>> of a major browser that supports data: URLs but doesn't support long
>> enough data: URLs to handle the script you want to handle? (And why
>> would
>> you have that script in text form instead of accessible from a URL?)
>>     
>
> I got burned so many times in the mid-90's by browser URL length problems,
> that I have not tried to exceed 255 characters in an URL since then.
>
> What you are saying though is this: Code that works correctly in one browser
> in one 100% spec-compliant browser may not work correctly in a different
> 100% spec-compliant browser. And that is not an acceptable situation.
>
> The more I write and revise my responses to your message, the more I realize
> that probably 99% of my objections are caused by the lack of a proper
> specification around data: URLs. I have submitted a spec proposal via the
> bug tracker to add it to the HTML spec. :)
>   
Problem with data URLs is also in the fact that they are almost not 
usable for using  in static
HTML document. For dynamic, generated html  they are probably fine but 
when attribute value spans
three pages is not to be read by human.

I understand motivation of having Worker script to be placed in separate 
documents/files.
It appears as this is the only way to avoid execution of the script in 
main thread. It has to live in
separate document. Not perfect of course as it brings some uncertainty 
in the algorithm - when it will really
start and will it start at all?.
> for (i = 0; i <= 1000000; i++) {
> arrayOfMessagePorts[i] = createWorker(arrayOfURLs[i]);
> }
>
> Yes, I know that it is an extreme example (not really, if you want to do
> something to the individual pixels of an image in parallel...), but it
> illustrates the problem well. If the createWorker(URL) method does not
> block, you can easily trash the RAM situation by creating a million thread
> objects like this. From my experience doing just this in other languages, I
> can tell you that it gets ugly. On the other hand, without our draft
> explicitly stating how a browser should perform a throttle, the developer
> has no clue how to write code and take the possibility of throttling into
> account.
>   
UA usually have some cap on how many simultaneous connections can be 
used by http client.
And yet "A single-user client SHOULD NOT maintain more than 2 
connections with any server or proxy. " [1]
In case of Workers UA shall use some intrinsic limit too. I think it is 
enough for createWorker() to throw
an exception if allowed maximum is reached.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html

Received on Monday, 21 July 2008 21:21:54 UTC