W3C home > Mailing lists > Public > public-html@w3.org > July 2008

Re: Workers

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Sat, 19 Jul 2008 17:28:20 -0700
Message-ID: <488286A4.7050207@terrainformatica.com>
To: Ian Hickson <ian@hixie.ch>
CC: public-html@w3.org

Ian Hickson wrote:
> On Sat, 19 Jul 2008, Andrew Fedoniouk wrote:
>>> On the backend it is certainly the case that implementations will have 
>>> to be very careful in their coding. This is independent of the Workers 
>>> spec, though.
>> By Workers you introduce new entity - shared access to the same objects 
>> local data storages and databases. I think we should mention that DB or 
>> local storages are being manipulated in exclusive mode - if DB is open 
>> by one Worker or main thread then it is not available by any means in 
>> other threads. That will simplify life.
> This would also lead to deadlocks or unexpected failures of Web author 
> code, which is far worse than making implementations harder.
> Implementations already have to deal with this anyway, since multiple 
> pages from the same domain can access the same database at the same time.

Ok, it means then that local storages and databases can be used
for passing structured information between threads and pages in runtime. 
That is good per se but will make implementation a bit harder.

>> It is not clear why you need DOM Event in this case then. [...] If DOM 
>> is isolated then it is isolated completely. No objects implementing any 
>> DOM interfaces must be available. Otherwise it will be nightmare for 
>> implementors.
> We need DOM Events because they are the event structure of the Web. They 
> are separate and distinct from the DOM Core's Node objects.
> Inventing our own parallel eventing construct would just be duplication of 
> effort without benefit, as I ses it.

As it is about JS only then there are more effective and flexible 
options available, see below.

>> Messages here are arbitrary JSON objects as far as I understand.
> JSON is a serialisation, I'm not sure what you mean by this. There's no 
> serialising going on here.

I mean following:
Beside of notation JSON also establishes strict [sub]set of objects
you are able to pass through. E.g. you can use Array or Object 
(key/value map) but you cannot pass e.g. DOM Element or RegExp.
In these terms JSON is a safe set for inter-process and inter-thread 

It would be nice if threads will be allowed to pass such objects - 
structured messages if you wish. UA can provide effective implementation 
of serialization in this case so to avoid parsing of strings.

Andrew Fedoniouk.

Received on Sunday, 20 July 2008 00:29:06 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:34 UTC