On Mon, Nov 30, 2009 at 8:08 PM, Maciej Stachowiak m...@apple.com wrote:
Would it be fair to say the goal for SharedScript is just to share code and
data (to reduce memory use of multiple instances of GMail), and not network
connections, timers, or other APIs based on async callbacks
On Tue, Dec 1, 2009 at 9:15 AM, Michael Davidson m...@google.com wrote:
A third improvement: When we adopt the HTML5 notification API for showing
users new mail or incoming chat notifications we will only show one
notification regardless of the number of Gmail tabs that are open. Today
each
One question about version conflicts and how they might get worse; sorry if
it's already been addressed. What happens if a user has an old version of
an application like Gmail open and then tries to open a new window to the
app, after developers have added new features? I presume the new window
Fair enough-- it sounds like SharedScript could improve things in that
sense. Though shutting down the app might now mean hunting down and
closing all the tabs that have it open, if not restarting the browser. (To
be honest, I'm not sure how many copies of Gmail I have open right now, but
I tend
On Tue, 1 Dec 2009, Michael Davidson wrote:
On Mon, Nov 30, 2009 at 8:08 PM, Maciej Stachowiak m...@apple.com wrote:
Would it be fair to say the goal for SharedScript is just to share
code and data (to reduce memory use of multiple instances of GMail),
and not network connections,
On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 1 Dec 2009, Michael Davidson wrote:
No, we definitely want to share network connections. We'd like users to
be able to have an arbitrary number of Gmail windows open without
running into the browser connection limit.
On Tue, 1 Dec 2009, Michael Davidson wrote:
On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 1 Dec 2009, Michael Davidson wrote:
No, we definitely want to share network connections. We'd like users
to be able to have an arbitrary number of Gmail windows open
Just to provide some history...
An intrinsic aspect of the SharedScript proposal is that scripting across
the page / sharedScript boundary should be very fast. When coming up with
the original proposal, we were careful to not require singleton semantics
that would work against that goal (by
Reading this, I am reminded of a great commentary by Alex Russell,
written nearly 3 years ago:
http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
Despite of what I may think about SharedScript, I am certain that
waiting -- whether for standards community or Web developers to
embrace or
http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
What a great rant :)
I'm also reminded of this quote...
The reasonable man adapts himself to the world. The unreasonable man
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man.
On Mon, Nov 30, 2009 at 1:17 PM, Alexey Proskuryakov a...@webkit.org wrote:
On 30.11.2009, at 9:55, Dimitri Glazkov wrote:
If we really want to move the Web platform forward, we can't afford a
feedback
cycle this long.
Per http://webkit.org/projects/goals.html, it doesn't seem that we
On Nov 30, 2009, at 9:55 AM, Dimitri Glazkov wrote:
Reading this, I am reminded of a great commentary by Alex Russell,
written nearly 3 years ago:
http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
Despite of what I may think about SharedScript, I am certain that
waiting -- whether
On Mon, Nov 30, 2009 at 1:45 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 30, 2009, at 9:55 AM, Dimitri Glazkov wrote:
Reading this, I am reminded of a great commentary by Alex Russell,
written nearly 3 years ago:
http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
Despite
On Nov 30, 2009, at 1:51 PM, David Hyatt wrote:
On Nov 30, 2009, at 3:33 PM, Maciej Stachowiak wrote:
Based on this, I agree with Sam's opinion that we should wait and
see how workers (and in particular SharedWorker) play out before we
take up this feature.
Regards,
Maciej
While I
There are a lot of people inside Google that have a lot of experience with
web standards, browsers, and web apps that seem to think this is useful and
worth the effort to experiment with it.
Who exactly inside Google is waiting to build a new service, feature, or
experiment using
On Mon, Nov 30, 2009 at 1:33 PM, Maciej Stachowiak m...@apple.com wrote:
My impression from WHATWG and from TPAC is that the web standards community
and other browser implementors don't really buy into the value of this
feature, so I think there's good odds we would end up in the orphan
On Mon, Nov 30, 2009 at 1:54 PM, Geoffrey Garen gga...@apple.com wrote:
There are a lot of people inside Google that have a lot of experience
with web standards, browsers, and web apps that seem to think this is useful
and worth the effort to experiment with it.
Who exactly inside Google is
On Nov 30, 2009, at 3:55 PM, Peter Kasting wrote:
On Mon, Nov 30, 2009 at 1:33 PM, Maciej Stachowiak m...@apple.com
wrote:
My impression from WHATWG and from TPAC is that the web standards
community and other browser implementors don't really buy into the
value of this feature, so I think
On Nov 30, 2009, at 1:58 PM, David Hyatt wrote:
On Nov 30, 2009, at 3:45 PM, Maciej Stachowiak wrote:
WebKit (or at least the mainline) is not necessarily a great place
for experiments. As our Project Goals say: WebKit is an
engineering project, not a science project.
We could name a couple of big ones (GMail was already mentioned before),
they already have designs ready to go into test as soon as they get
SharedScript in a dev build. If there was no desire from actual app
developer teams for SharedScript, we would not have the reason to continue
with it long
On 30.11.2009, at 14:05, Dmitry Titov wrote:
That also pretty much means if we won't have SharedScript, we'll
need to explore other opportunities toward efficient sharing of code
and data which does not make people to write a multithreaded UI as
SharedWorker solution would do. We have
On Mon, Nov 30, 2009 at 2:30 PM, Alexey Proskuryakov a...@webkit.org wrote:
On 30.11.2009, at 14:05, Dmitry Titov wrote:
That also pretty much means if we won't have SharedScript, we'll need to
explore other opportunities toward efficient sharing of code and data which
does not make people
In Chrome, a SharedWorker is reachable from any WebKit process, whereas a
SharedScript would only be reachable within a WebKit process. This is an
interesting distinction, and I can imagine some use cases for SharedWorker
that SharedScript could not address. (This distinction arises
On Mon, Nov 30, 2009 at 2:56 PM, Oliver Hunt oli...@apple.com wrote:
In Chrome, a SharedWorker is reachable from any WebKit process, whereas a
SharedScript would only be reachable within a WebKit process. This is an
interesting distinction, and I can imagine some use cases for SharedWorker
Just a note:
In Chrome, a SharedWorker is reachable from any WebKit process, whereas a
SharedScript would only be reachable within a WebKit process. This is an
interesting distinction, and I can imagine some use cases for SharedWorker
that SharedScript could not address. (This
I don't think it's correct to say that SharedWorkers are not useful and we
need a SharedScript instead. They are different things and can address
different use cases. For example, SharedWorker is great to make sure there
is only one 'app instance' running - exactly because it is shared
As an aside (that doesn't necessarily detract from your point) I'd say that
the WebWorker spec is fairly clear in intent: that there will be a single
sharedworker per domain/name within a given UserAgent. You'd have to parse
the idea of a user agent fairly finely (i.e. treat separate Chrome
On Mon, Nov 30, 2009 at 3:08 PM, Geoffrey Garen gga...@apple.com wrote:
Just a note:
In Chrome, a SharedWorker is reachable from any WebKit process, whereas a
SharedScript would only be reachable within a WebKit process. This is an
interesting distinction, and I can imagine some use
On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote:
I don't think it's correct to say that SharedWorkers are not useful and we
need a SharedScript instead. They are different things and can address
different use cases. For example, SharedWorker is great to make sure there is
only one 'app
On Mon, 30 Nov 2009, Dmitry Titov wrote:
That also pretty much means if we won't do SharedScript, we'll need to
explore other opportunities toward efficient sharing of code and data
which does not make people to write a multithreaded UI as SharedWorker
solution would do. We have
Does anyone have a link to the spec?
On Mon, Nov 30, 2009 at 4:07 PM, Oliver Hunt oli...@apple.com wrote:
On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote:
I don't think it's correct to say that SharedWorkers are not useful and we
need a SharedScript instead. They are different things and
On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 30 Nov 2009, Dmitry Titov wrote:
That also pretty much means if we won't do SharedScript, we'll need to
explore other opportunities toward efficient sharing of code and data
which does not make people to write a
Guys, this thread is getting out of hand. I am waiting for Godwin's
law to strike any second now.
Can I make a gentle suggestion to perhaps break out new conversations
into separate topics? :)
Your friendly neighborhood mailing list maid,
:DG
___
On Mon, Nov 30, 2009 at 4:29 PM, David Levin le...@google.com wrote:
On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 30 Nov 2009, Dmitry Titov wrote:
That also pretty much means if we won't do SharedScript, we'll need to
explore other opportunities toward
On Mon, Nov 30, 2009 at 4:15 PM, Ian Hickson i...@hixie.ch wrote:
The pushback on SharedWorkers at Google is because Google teams don't want
to rewrite their apps to work with workers -- SharedScript lets them
handle some of the cases SharedWorkers would get them, without having to
rewrite
On Nov 30, 2009, at 4:35 PM, Jeremy Orlow wrote:
To be fair, app developers in general want to do everything
synchronously but we (in standards land) have pushed back very hard
because software research has shown that such interfaces are very
difficult (if not impossible) to
On Nov 30, 2009, at 5:09 PM, Maciej Stachowiak wrote:
On Nov 30, 2009, at 4:35 PM, Jeremy Orlow wrote:
To be fair, app developers in general want to do everything
synchronously but we (in standards land) have pushed back very hard
because software research has shown that such
On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote:
By the way, we could enable the SharedScript programming model at much
lower WebKit-level implementation cost and with much less API surface as
follows:
- Allow Window to be passed via the structured clone algorithm
On Mon, Nov 30, 2009 at 5:37 PM, Dmitry Titov dim...@chromium.org wrote:
On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com wrote:
By the way, we could enable the SharedScript programming model at much
lower WebKit-level implementation cost and with much less API surface as
On Mon, Nov 30, 2009 at 5:43 PM, Jeremy Orlow jor...@chromium.org wrote:
In addition, everything you mentioned would be a good use case for a
SharedWorker since it'd be fairly detached from UI and is async.
Is it intentional or unintentional that this misses the point that some
logic items is
On Nov 30, 2009, at 5:37 PM, Dmitry Titov wrote:
On Mon, Nov 30, 2009 at 5:21 PM, Maciej Stachowiak m...@apple.com
wrote:
By the way, we could enable the SharedScript programming model at
much lower WebKit-level implementation cost and with much less API
surface as follows:
- Allow
On Nov 30, 2009, at 3:43 PM, Dmitry Titov wrote:
I don't think it's correct to say that SharedWorkers are not useful
and we need a SharedScript instead. They are different things and
can address different use cases. For example, SharedWorker is great
to make sure there is only one 'app
I believe that the offline gmail team uses the Gears flavor of shared
workers and is planning to migrate to the HTML5 version once DB access is
supported from within worker context in shipping browsers.
So I guess that Gmail would be a candidate app that has asked for both.
-atw
On Mon, Nov 30,
Following up, I think this highlights the distinct set of use cases that
shared workers and shared script address:
SharedWorkers are a great platform for when you have a single database that
is shared across multiple instances of your web app, and you want to
coordinate updates to that database.
Hi folks -
I'm one of the Gmail engineers who worked on the SharedScript proposal. I
thought I'd jump in and give my perspective as a developer.
The thread has gotten a little broad, so apologies if I miss something. It
seems to me there are a few separate questions being discussed:
1) In
On Nov 30, 2009, at 6:16 PM, Drew Wilson wrote:
Following up, I think this highlights the distinct set of use cases
that shared workers and shared script address:
SharedWorkers are a great platform for when you have a single
database that is shared across multiple instances of your web
Hi Michael,
On Nov 30, 2009, at 7:13 PM, Michael Davidson wrote:
Hi folks -
I'm one of the Gmail engineers who worked on the SharedScript
proposal. I thought I'd jump in and give my perspective as a
developer.
Thanks a lot for sharing your perspective. Hearing it directly is
helpful.
On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 30, 2009, at 6:16 PM, Drew Wilson wrote:
Following up, I think this highlights the distinct set of use cases that
shared workers and shared script address:
SharedWorkers are a great platform for when you have a
On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 30, 2009, at 6:16 PM, Drew Wilson wrote:
Following up, I think this highlights the distinct set of use cases that
shared workers and shared script address:
SharedWorkers are a great platform for when you have a
On Nov 30, 2009, at 8:31 PM, Darin Fisher wrote:
On Mon, Nov 30, 2009 at 7:55 PM, Maciej Stachowiak m...@apple.com wrote:
On Nov 30, 2009, at 6:16 PM, Drew Wilson wrote:
Following up, I think this highlights the distinct set of use cases that
shared workers and shared script
What I meant was it would be nice, for the sake of discussion, to share the
experience of real life applications that used SharedWorkers or inter-window
communications for sharing of significant portions of code and data. Google
apps may be a partial example but it is a real life example of
Hi Dmitry,
As I have noted to others on the Chrome team, I do not think this is good
idea and I don't think we should have it in WebKit. It adds extra
complexity to WebKit and gives little beyond what is possible using
inter-window communication and SharedWorkers. I think we need to give more
Hi Sam!
Thanks a lot for sharing your perspective! I really wish your reply
had, in addition to the statement of the opinion, an argument or just
more explanation of why you think so. I think we covered SharedWorkers
and inter-window communication in the previous discussions and in the
design
On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov dim...@chromium.org wrote:
BTW, could you tell what's the 'course' that would be reverted?
Meaning, before we decide that SharedWorkers and inter-window communication
are insufficient, and a further proposal should be entertained by the
standards
Hi webkit!
I'm starting to work on actual implementation of GlobalScript experimental
API http://docs.google.com/View?id=dxv3cth_2rnj9wffz and started to post
patches (hopefully in reviewable portions). There is an
uber-bughttps://bugs.webkit.org/show_bug.cgi?id=31317which has plan
of
55 matches
Mail list logo
