Re: Limited DOM in Web Workers

Surely the idea is to do more on the client? I for one am using XML web
service APIs on the servers. The client JavaScript/HTTP is downloaded once
into the AppCache. We have 3 or 4 different Web-Service servers performing
different functions (say a registration service, an upload service,
geo-location correction service). Some of the services are provided by other
people. (geo-location correction service is provided directly by NOAA for
example).

The 'client' runs the complete application written in JavaScript, and
queries each service in XML. This uses the 'client' CPU to do the work. Its
like having an N machine cluster super-computer where N equals the number of
users (so CPU sales perfectly 1 to 1).

IMHO this is the future of the internet/web, and this is what the
webapps-working group should be trying to encourage and make easier.

On this basis client side XML is central to what a web-app is. Although I
would prefer to use JSON in our own services we have to be able to use
web-services provided by other people too.


Cheers,
Keean.


On 9 January 2011 08:32, ATSUSHI TAKAYAMA <taka.atsushi@googlemail.com>wrote:

> Hi,
>
> On Sun, Jan 9, 2011 at 2:29 AM, Jack Coulter <jscinoz@jscinoz.org> wrote:
> > The real question is: Do we want to create something new? Perhaps at
> least
> > superficially resembling the DOM api, for developer familiarity. Or do we
> > simply want to have E4X universally supported, both in workers, and in
> > the main thread?
>
> Why don't you use a JavaScript implementation of DOM for now? And if
> so many developers take such approach, then browser vendors can
> consider implementing it natively. (But the reality is, XML is just
> hardly ever used on client side)
> I know that jsdom https://github.com/tmpvar/jsdom already has some use
> cases with Node.js and some people run YUI or jQuery on top of it.
>
> A.TAKAYAMA
>
>