Commenting in general on this (and not specifically the GlobalScript
proposal), I think the outcome of discussions on this list too often is
solve it with a single-page Ajax app. In contrast, I think HTML5 should
address the needs of multi-page (including all server-side oriented) apps
with at
On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 7 Sep 2009, Dimitri Glazkov wrote:
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hicksoni...@hixie.ch wrote:
Another case is an application that uses navigation from page to page
using menu or some site navigation
to say that every app should necessarily be a single complex AJAX page
morphing itself. That in itself may be a serious limitation.
Agree very much so.
On Tue, Sep 15, 2009 at 5:54 PM, Dmitry Titov dim...@chromium.org wrote:
On Mon, Sep 14, 2009 at 4:41 AM, Ian Hickson i...@hixie.ch wrote:
On Mon, 7 Sep 2009, Dimitri Glazkov wrote:
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hicksoni...@hixie.ch wrote:
Another case is an application that uses navigation from page to page
using menu or some site navigation mechanism. Global Script Context
could keep the application state so it
On Mon, 07 Sep 2009 23:30:42 +0200, Dimitri Glazkov
dglaz...@chromium.org wrote:
My big issue with pushHistory is that it messes with the nature of the
Web: a URL is a resource you request from the server. Not something
you arrive to via clever sleight of hand in a user agent. So, you've
On Tue, Sep 8, 2009 at 6:12 AM, Anne van Kesterenann...@opera.com wrote:
FWIW, this is why I think pushState is great. If you bookmark it and later
visit that page it allows the server to directly give the right content back
instead of first loading a page which then fetches additional content
On Tue, 08 Sep 2009 17:57:36 +0200, Dimitri Glazkov
dglaz...@chromium.org wrote:
On Tue, Sep 8, 2009 at 6:12 AM, Anne van Kesterenann...@opera.com
wrote:
FWIW, this is why I think pushState is great. If you bookmark it and
later
visit that page it allows the server to directly give the right
On Sun, 30 Aug 2009, Michael Nordman wrote:
These arguments against the proposal are not persuasive. I remain of the
opinion that the GlobalScript proposal has merit.
That's possible; I would recommend taking up a Global Script proposal in
the public-webapps working group, though, as it is
On Thu, Sep 3, 2009 at 7:30 AM, Ian Hicksoni...@hixie.ch wrote:
On Mon, 31 Aug 2009, Mike Shaver wrote:
The multiple server-side processes that end up involved over the course
of the user's interaction do need to share state with each other, and
preserving blocking semantics for accessing
I'm finding it hard to envision the kind of applications that are going to
be created that will need to take advantage of multiple cores when there are
orders of magnitude more cores than applications. Do you believe that
we're going to see a fundamental shift in the kinds of things people are
Ian Hickson wrote:
Given that all frames in a
browsing context have to be on the same thread,
regardless of domain, then unless we put all the
browsing contexts on the same thread, we can't
guarantee that all frames from the same domain
across all browsing contexts will be on the same
(Grabbing from the end...)
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@hixie.ch wrote:
implementation experience before specifying it. But I really don't think
it is the direction we should be taking the platform in. Granted,
programmers today don't want to use threads -- but, well,
On Sat, Aug 29, 2009 at 5:40 PM, Ian Hicksoni...@hixie.ch wrote:
Furthermore, consider performance going forward. CPUs have pretty much
gotten as fast as they're getting -- all further progress is going to be
in making multithreaded applications that use as many CPUs as possible. We
should
These arguments against the proposal are not persuasive. I remain of the
opinion that the GlobalScript proposal has merit.
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Aug 2009, Dmitry Titov wrote:
Currently there is no mechanism to directly share DOM, code
On Sat, Aug 29, 2009 at 2:40 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 17 Aug 2009, Dmitry Titov wrote:
Currently there is no mechanism to directly share DOM, code and data on
the same ui thread across several pages of the web application.
Multi-page applications and the sites that
On Mon, 17 Aug 2009, Dmitry Titov wrote:
Currently there is no mechanism to directly share DOM, code and data on
the same ui thread across several pages of the web application.
Multi-page applications and the sites that navigate from page to page
would benefit from having access to a
Patrick Mueller wrote:
Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when
creating/connecting
to an instance of a global-script... in which case each client page
expresses something more
Dmitry had a later note which combined creation of the context and loading
of the script. But I suspect one thing people will want to do, in
development anyway, is load multiple scripts into a context - like you can
in workers. Which would mean we'd still need a function to load a script,
I did mention 2 forms of script load indeed, mostly trying to find a
simplest form that will be also consistent with what's already there in the
spec.
In terms of loading scripts, it seems the GlobalScript is quite similar to
what SharedWorker does to load its scripts.When creating SharedWorker,
BTW, the WorkerGlobalScope.importScript() API blocks the current thread of
execution, which is probably not acceptable for code executed from page
context. So for globalscripts we'll need some way to do async notifications
when the loading is complete, and report errors. We may also want to have
Agreed, blocking semantics are definitely not OK for GlobalScript, this
context-type calls for some form of async importScript functionality. If
order load order matters, apps certainly could defer loading the scripts
until what they depend on have been already loaded already. Where load order
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype
in something like Rhino (or my nitro_pie python wrapper for
JavaScriptCore), at least API wise, so we could see what the user-land
code would look like, and see it run.
I developed a simulator
Mike Wilson wrote:
Another thing:
From the proposal it seems it will be possible for the GlobalScript context
to keep references to objects (DOM, JS data, etc) private to pages, and vice
versa possible for pages to keep references to GlobalScript objects. This
also opens up for a new way for
On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilsonmike...@hotmail.com wrote:
Another thing:
From the proposal it seems it will be possible for the GlobalScript context
to keep references to objects (DOM, JS data, etc) private to pages, and vice
versa possible for pages to keep references to
On Fri, Aug 21, 2009 at 11:10 AM, Aaron Boodman a...@google.com wrote:
On Fri, Aug 21, 2009 at 4:50 AM, Mike Wilsonmike...@hotmail.com wrote:
Another thing:
From the proposal it seems it will be possible for the GlobalScript
context
to keep references to objects (DOM, JS data, etc)
On Fri, Aug 21, 2009 at 6:37 AM, Patrick Mueller pmue...@muellerware.orgwrote:
Patrick Mueller wrote:
Time to work on some examples. This would relatively easy to prototype in
something like Rhino (or my nitro_pie python wrapper for JavaScriptCore), at
least API wise, so we could see what
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new GlobalScript(scriptUrl);
Hi,
a general comment on the interesting GlobalScript proposal for helping
to structure client-side portions of a web application - have people looked
in detail at existing work experiences made there? Like .NET's AppDomains.
cheers
--sigbjorn (s...@opera.com)
On 8/21/2009 21:47, Michael
Michael Nordman wrote:
I'm confused about the manual loading of the script into the context? The
original proposal called for providing a script url when creating/connecting
to an instance of a global-script... in which case each client page
expresses something more like...
globalScript = new
Jeremy Orlow wrote:
Btw, I thought I'd just point out that the proposal mentions this case:
From the proposal text: All pages connected to the same Global Script
should run on the same thread, in the same process. Since this is not
always technically possible, it should be legal (and not break
This looks interesting.
Dmitry Titov wrote:
A web page will be able to create a Global Script and connect to it, as in
this example:
var context = new GlobalScript(); // perhaps 'webkitGlobalScript' as
experimental feature?
context.onload = function () {...}
context.onerror = function ()
On Wed, Aug 19, 2009 at 10:48 AM, Dmitry Titov dim...@google.com wrote:
On Wed, Aug 19, 2009 at 7:37 AM, Patrick Mueller
pmue...@muellerware.orgwrote:
var context = new GlobalScript(); // perhaps 'webkitGlobalScript' as
experimental feature?
context.onload = function () {...}
Patrick Mueller wrote:
Or perhaps these GlobalScripts - should really be called
GlobalObjects or GlobalContexts maybe; SharedScope?
I like Shared as this is the term used in SharedWorkers
to identify something that can be shared between multiple
pages. SharedContext?
Best regards
Mike
Michael Nordman wrote:
I understand the desire for early warning that a page *may* want to utilized
a GlobalScript. A 'hint' could be useful to a multi-process UA. It's not
clear to me that this is what Patrick was referring to... Patrick?
I wasn't thinking as a hint for the browser, but
Dmitry Titov wrote:
The return value from a constructor is the Global Script's global scope
object. It can be used to directly access functions and variables defined
in global scope of the Global Script. While this global scope does not have
'window' or 'document' and does not have visual page
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller pmue...@muellerware.orgwrote:
Dmitry Titov wrote:
The return value from a constructor is the Global Script's global scope
object. It can be used to directly access functions and variables defined
in global scope of the Global Script. While
Michael Nordman wrote:
On Wed, Aug 19, 2009 at 1:34 PM, Patrick Mueller pmue...@muellerware.orgwrote:
Can I create additional GlobalScript's from within an existing
GlobalScript?
That's a good question...
(just having fun... oh the tangled web we weave;)
I'm not sure any has thought thru
[mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Dmitry Titov
Sent: den 17 augusti 2009 23:38
To: wha...@whatwg.org
Subject: [whatwg] Global Script proposal.
Dear whatwg,
The previous discussion about shared page and persistence has sent
us back
Sent: den 17 augusti 2009 23:38
To: wha...@whatwg.org
Subject: [whatwg] Global Script proposal.
Dear whatwg,
The previous discussion about shared page and persistence has sent
us back 'to the drawing board', to think again what is the essence of the
feature and what's
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote:
[2] As I understand it, the new GlobalScript construct is
a context that can be shared by all browsing contexts in
the user agent.
It can, but with a caveat: in case of user agents that are multi-process, in
some cases
Michael Nordman wrote:
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote:
Threading:
This is the unavoidable question ;-) How do you envision
multiple threads accessing this shared context to be
coordinated?
Nominally, they don't. In our design for chrome's multi-process
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote:
Michael Nordman wrote:
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote:
Threading:
This is the unavoidable question ;-) How do you envision
multiple threads accessing this shared context to be
On Tue, Aug 18, 2009 at 12:32 PM, Aaron Boodman a...@google.com wrote:
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilsonmike...@hotmail.com wrote:
Michael Nordman wrote:
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com
wrote:
Threading:
This is the unavoidable question
On Tue, Aug 18, 2009 at 12:20 PM, Mike Wilson mike...@hotmail.com wrote:
Michael Nordman wrote:
On Tue, Aug 18, 2009 at 6:07 AM, Mike Wilson mike...@hotmail.com wrote:
Threading:
This is the unavoidable question ;-) How do you envision
multiple threads accessing this shared context to be
Dear whatwg,
The previous discussion about shared page and persistence has sent us back
'to the drawing board', to think again what is the essence of the feature
and what's not important. Talking with web apps developers indicates the
most of benefits can be achieved without dangerous background
45 matches
Mail list logo
