[webkit-dev] How Getter of Any Runtime as well as Built-in Object Works?
Nitin
codomaker at gmail.com
Wed May 27 01:13:08 PDT 2009
Hi ,
I am trying to learn how the getter of any Built-in Type object works.
I've some knowledge like every Built-in Object has a getOwnPropertySlot ,But
whats the exact Flow, I m trying to figure out.
Please do guide.
Thank you.
On Wed, May 27, 2009 at 9:35 AM, <webkit-dev-request at lists.webkit.org>wrote:
> Send webkit-dev mailing list submissions to
> webkit-dev at lists.webkit.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> or, via email, send a message with subject or body 'help' to
> webkit-dev-request at lists.webkit.org
>
> You can reach the person managing the list at
> webkit-dev-owner at lists.webkit.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of webkit-dev digest..."
>
>
> Today's Topics:
>
> 1. Re: SharedWorkers alternate design (Jeremy Orlow)
> 2. Re: Notifications API (Drew Wilson)
> 3. Question about table width property. I'm not sure if this
> issue is bug or not. (Kyounga Ra)
> 4. Re: SharedWorkers alternate design (Sam Weinig)
> 5. Re: Notifications API (Sam Weinig)
> 6. Re: SharedWorkers alternate design (Sam Weinig)
> 7. Re: SharedWorkers alternate design (Jeremy Orlow)
> 8. Re: SharedWorkers alternate design (Jeremy Orlow)
> 9. Re: SharedWorkers alternate design (Michael Nordman)
> 10. Re: SharedWorkers alternate design (Jeremy Orlow)
> 11. Re: SharedWorkers alternate design (Michael Nordman)
> 12. Re: SharedWorkers alternate design (John Abd-El-Malek)
> 13. Re: SharedWorkers alternate design (John Abd-El-Malek)
> 14. Re: SharedWorkers alternate design (Jeremy Orlow)
> 15. Re: Notifications API (Sam Weinig)
> 16. Re: SharedWorkers alternate design (David Levin)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 26 May 2009 16:12:15 -0700
> From: Jeremy Orlow <jorlow at chromium.org>
> To: Drew Wilson <atwilson at google.com>
> Cc: Darin Adler <darin at apple.com>, WebKit Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <5dd9e5c50905261612lb4d1600t45a416d7617f0402 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> The common case is definitely that we know whether we want the proxy (for
> IPC) or the implementation at compile time. In some cases (like Chromium)
> this is not known until initialization time. So the ideal is a clean way
> to
> handle the "not known until initialization" while optimizing for the
> compile
> time case. Here's a proposal:
>
>
> For the compile time decision case, do everything the same as it's done in
> ResourceRequest: Have an interface (StorageBackendInterface), a "Base"
> class (except in this case we'll have 2 which we'll call
> "StorageBackendImpl" and "StorageBackendProxy"), and then the class
> everything uses (StorageBackend). The decision of which base class
> StorageBackend should inherit from can be made based on a preprocessor
> define. Everything basically works as Maciej suggested.
>
> For the initialization time decision case, we flip things on their head: we
> prepend "virtual" to every method declaration in StorageBackend (via a
> define that's either "virtual" or "") and switch the inheritance order so
> that StorageBackendImpl/Proxy inherit from StorageBackend. Now all those
> casts we were doing above (i.e. StorageBackendImpl casting itself to
> StorageBackend and calling a method) are completely legal type system wise
> (because they're casting it to a base class). Additionally, any calls to
> functions that used to be inherited (i.e. StorageBackend making a call to
> something in StorageBackendImpl) are ok because it's just doing a virtual
> dispatch. (The key is that every function shared between the
> StorageBackend
> and the Impl/Proxy needs to be declared in the Interface.)
>
>
> This still seems really ugly and overly complicated. I'm actually about to
> send out code for https://bugs.webkit.org/show_bug.cgi?id=25376 that uses
> plain old virtual dispatch and everything runs at exactly the same speed it
> used to. (I made an ad-hoc benchmark so I could double check such things.)
> So....I'm really not sure all of this trickery makes sense for what I'm
> working on, but it might be necessary elsewhere.
>
> J
>
>
> On Tue, May 26, 2009 at 11:11 AM, Jeremy Orlow <jorlow at chromium.org>
> wrote:
>
> > Note that Chromium uses the same binary/libraries for the render process
> > and the browser process, which means that the decision can't be made in
> > compile time for us.
> >
> > There might be ways (like what you mentioned) to allow the compiler to
> skip
> > all the virtual stuff for implementations where the decision can be made
> in
> > compile time (the normal case). I've got some ideas....I'll try to
> explain
> > them when I get a second later this afternoon.
> >
> > J
> >
> > On Tue, May 26, 2009 at 10:43 AM, Drew Wilson <atwilson at google.com>
> wrote:
> >
> >> Thanks for the explanation, Maciej. I actually looked at ResourceRequest
> >> prior to sending my mail, but I wasn't clear what makefile magic was
> being
> >> used to load the correct version of ResourceRequest.h for a given
> platform.
> >>
> >> For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see
> >> only two references to ResourceRequest.h: platform/network/curl and
> >> platform/network/cf, but clearly we might want to use the chromium/ or
> win/
> >> versions as well. Can someone give me a quick explanation of how the
> >> platform-specific version is selected at compile time?
> >>
> >> Do we have a naming convention for the "default" implementation? I'm
> >> expecting there to be two versions of SharedWorkerRepository - the
> chromium
> >> version, and the <everything else> version.
> >>
> >> -atw
> >>
> >>
> >> On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak <mjs at apple.com
> >wrote:
> >>
> >>>
> >>> On May 26, 2009, at 10:21 AM, Darin Adler wrote:
> >>>
> >>> On May 26, 2009, at 10:16 AM, Drew Wilson wrote:
> >>>>
> >>>> OK, I've got two strong votes for the interface + static factory
> >>>>> approach. Any objections from the rest of the WebKit team? If I don't
> hear
> >>>>> any counter proposals, I'll do that.
> >>>>>
> >>>>
> >>>> I think it's unpleasant to pay run-time cost for a compile-time
> choice.
> >>>> Sure, sometimes the extra cost is no big deal, but sometimes it can be
> a big
> >>>> deal and I see no reason to choose idioms that use virtual functions
> if
> >>>> there are equally good or better ones that don't.
> >>>>
> >>>> Are there really no better techniques than abstract base classes and
> >>>> virtual functions for this sort of compile-time switch? How about the
> >>>> technique used for ResourceRequest and ResourceResponse? Maybe Darin
> Fisher
> >>>> can explain that one.
> >>>>
> >>>
> >>> I agree with Darin's comments here. We've tried hard to avoid using
> >>> runtime polymorphism for compile-time choices. Here it's probably not
> >>> performance-critical, but it can be avoided.
> >>>
> >>> The ResourceRequestBase / ResourceRequest model (due to Darin Fisher)
> >>> seems pretty clean to me. I would like to see more of our classes with
> >>> port-specific implementation details move to this style. I think it
> could
> >>> work for SharedWorkerRepository.
> >>>
> >>> The basic idea is this. Let's say you have a class FooBar.
> >>>
> >>> - You define a FooBarBase class that has the cross-platform interface
> and
> >>> data members. But not all the methods are actually implemented in the
> >>> cross-platform code. All of its constructors are protected so the class
> >>> cannot be instantiated directly.
> >>> - Each port subclasses FooBarBase to define FooBar, adding
> constructors,
> >>> platform-specific data members, and any needed platform-specific
> private
> >>> helpers or type conversions.
> >>> - Each port implements the methods of FooBarBase that are
> >>> platform-specific, freely downcasting to FooBar when needed since we
> have
> >>> guaranteed that every instance of FooBarBase is actually a FooBar.
> >>> - Cross-platform code using the class just uses FooBar. The Base class
> is
> >>> an implementation detail.
> >>>
> >>> (Darin F., please correct me if I have not done justice to this
> >>> technique.)
> >>>
> >>> Note that this method has no runtime cost - there's no need to use
> >>> virtual methods or other forms of runtime indirection. And there's no
> need
> >>> to #ifdef any headers, everything is controlled purely by including the
> >>> right platform specific FooBar.h so it can be handled by include paths.
> It's
> >>> a little subtle at first but I think it results in nice, understandable
> >>> code.
> >>>
> >>> I think we should document this technique as the preferred way to make
> >>> classes with port-specific implementation details and convert more of
> >>> WebCore/platform/ to this technique, as well as using it for new
> classes.
> >>>
> >>> Regards,
> >>> Maciej
> >>>
> >>>
> >>
> >> _______________________________________________
> >> webkit-dev mailing list
> >> webkit-dev at lists.webkit.org
> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >>
> >>
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/db3fa978/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Tue, 26 May 2009 16:20:00 -0700
> From: Drew Wilson <atwilson at google.com>
> To: John Gregg <johnnyg at google.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Notifications API
> Message-ID:
> <f965ae410905261620y3448691dk514327e8a3e4dc31 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> To give the list some insight into the discussions we've had with the
> Chrome
> UX folks:
>
> 1) We want to associate some set of enhanced permissions with a given
> origin
> (e.g. https://mail.yahoo.com), and we want the user to be presented with a
> single "do you want to grant permissions to https://mail.yahoo.com"
> dialog,
> rather peppering the user with a bunch of individual permission dialogs for
> each feature ("Yes, please allow mail.yahoo.com to use 100MB of local
> storage", "Yes, allow mail.yahoo.com to display notifications", "Yes,
> allow
> mail.yahoo.com to run in the background").
> 2) We want the timing of the permission grant UI to be under application
> control (as part of some kind of application user flow). So just visiting
> mail.yahoo.com would not suddenly popup an unexpected dialog - instead the
> application would have some UI along the lines of "Turn on desktop
> notifications" which would drive some app-specific UI flow, a part of which
> would involve the permission grant.
> 3) To prevent applications from spamming the user with unwanted permission
> dialogs, the user agent could only display permission grants in response to
> user input (similar to how popup blocking works). The intent is to drive
> application authors to build UI flow around the permission grant, and to
> prevent things like third-party ad domains from doing "drive-by" permission
> grants.
> 4) Once the user has denied the permission grant, we would not display them
> again. The user agent can provide its own UI for managing domains with
> permission grants, similar to how some applications have a popup blocking
> whitelist/blacklist.
> 5) Long term, we probably want the application to specify what permissions
> it wants and display those permissions as part of the permissions grant.
> Some folks have even requested that users have the ability to
> pick-and-choose which permissions they want to grant, but it's not clear
> that this is feasible (giving an origin the ability to run in the
> background, but then not giving it the ability to store data locally may
> not
> make sense). We weren't positive what the correct way to specify the
> desired
> permissions would be - array of identifier strings? Javascript object/hash
> of configuration params? URL to some kind of application manifest?
> 6) From an application standpoint, they need the ability to test whether
> they have permission (granted, ungranted, blocked) and the ability to
> request permissions (throws an exception if the current permission state ==
> blocked).
>
> This patch is already fairly large, which is why we were planning to drive
> the permissions API in a follow-on patch. Our current thinking was to have
> a
> simple API as John describes (getTrusted() and requestTrust()). Since
> there's not really any consensus around how to specify individual
> permissions, the API would not take any parameters so it would reflect a
> blanket "elevated trust" level for the application, with the intent of
> evolving this API based on feedback from whatwg and internal developers.
>
> -atw
>
> On Tue, May 26, 2009 at 2:32 PM, John Gregg <johnnyg at google.com> wrote:
>
> > On Tue, May 26, 2009 at 2:20 PM, Maciej Stachowiak <mjs at apple.com>
> wrote:
> >
> >>
> >> On May 22, 2009, at 10:19 AM, John Gregg wrote:
> >>
> >> Sure. We have the following plan for how to handle opt-in:
> >> - Use of the feature by script, if permission isn't granted to the
> >> origin, should throw an exception, not present permissions UI. So your
> >> insistent porn site would have no effect on the user.
> >> - A dialog box asking for permission should only appear in response to
> a
> >> user gesture like a click. So in the normal case, an application will
> >> present a user with a link "New: Desktop Calendar Notifications
> available!
> >> Click here to setup." And that link will present a prompt from the
> >> user-agent "Do you trust calendar.com? The site wants to display
> >> notifications on your desktop. [Yes/No]" If the user says yes, script
> >> running under that origin will have permission to show desktop
> >> notifications.
> >>
> >>
> >> To expose this flow, wouldn't you need a method in the API exposed to
> >> JavaScript that requests permission for notifications, rather than
> actually
> >> posting a notification? I don't see such a method in the submitted
> patch. It
> >> would not make sense for a link labeled "New: Desktop Calendar
> Notifications
> >> available! Click here to setup" to actually display a notification
> itself,
> >> I wouldn't think.
> >>
> >> Having a JavaScript API to request permissions, along with plumbing
> >> through the WebKit layer to allow a WebKit embedder to suitably prompt
> the
> >> user, would address most of my concerns.
> >>
> >
> > Yes, this would be necessary. It's actually part of the spec API I
> > originally proposed at
> >
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html(<http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-March/019113.html%28>"readonly
> bool trusted" attribute and "void requestTrust()" method), and I
> > was planning to submit in a follow-up patch. But if you prefer it come
> in
> > at the same time as the rest of the code, it can be done all at once. Do
> > you have any particular proposal for how to accomplish the "plumbing"?
> > Part of the thinking is that it would be nice to avoid overwhelming users
> > with lots of different permission UIs for individual native-app-like
> > features that will come up (persistent workers (if and when) & local
> > database quota come to mind).
> >
> > Thanks,
> > -John
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/71ced255/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Wed, 27 May 2009 08:58:04 +0900
> From: Kyounga Ra <kyounga.ra at gmail.com>
> To: webkit-dev <webkit-dev at lists.webkit.org>
> Subject: [webkit-dev] Question about table width property. I'm not
> sure if this issue is bug or not.
> Message-ID:
> <3494039a0905261658i4667f1ccv57f1b83b47330f79 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> I'm Kyounga interested in web browser.
>
> While I'm doing internet surfing, I found out Safari 4 has wrong rendering
> result on "Yhaoo".
> I investigated to figure out if this is really issue or just follows web
> standard.
> But, I'm confused to understand web standard.
>
> I attached the reduced test page.
>
> <div class=b> has "width :405px" , "display:table" , "padding-right,
> padding-left:10px", "border :1px"
> The sum of the children specifid width is 125(dt width) + 15(dd marging) +
> 257(dd width) =397.
> So, the space is enough.
> but, the <dd> content is laid out next line becuase the computed width for
> <div class=b> is 383.
> I think that the width property is computed by border edge.
> But, normally, by CSS 2.1 the width property means "content edge".
> For table, CSS 2.1 says
> anonymous table box width is border edge of table box(the child of
> anonymous
> box) and
> table width includes border-spacing and excluding border and padding.
>
> reference :
> http://www.w3.org/TR/CSS21/tables.html#model
> http://www.w3.org/TR/CSS21/tables.html#separated-borders
>
> Please make my confusion clear.
>
> Thank you in advance.
> Kyounga.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090527/0d564857/attachment-0002.html
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090527/0d564857/attachment-0003.html
> >
>
> ------------------------------
>
> Message: 4
> Date: Tue, 26 May 2009 17:00:57 -0700
> From: Sam Weinig <sam.weinig at gmail.com>
> To: John Abd-El-Malek <jam at google.com>
> Cc: Darin Adler <darin at apple.com>, WebKit Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <63a07bb10905261700q166cd1c8lbc18a336d70c0d7f at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek <jam at google.com>
> wrote:
>
> > I agree that this approach is powerful. However there are (not too
> > frequent) situations when a port like Chromium wants to use both the
> WebKit
> > implementation and its own implementation, switching in runtime. For
> > workers, this happened with WorkerContextProxy/WorkerObjectProxy which
> are
> > the interfaces that a worker object implements/uses. Since workers run
> in a
> > separate process from the renderer, we use our own implementations of
> these
> > interfaces that know about IPC etc. However once we're in the worker
> > process, we want to run nested workers in the same process, in which case
> we
> > want to use the WebKit implementation of these interfaces directly
> without
> > using Chromium's.
>
>
> This doesn't seem like a runtime choice, but rather a "use-time" choice.
> In
> the main context, you want use one implementation and in the worker
> context,
> another one. This to me implies two different objects with different
> names.
> In non-multiprocess implementations of WebKit, these two objects could be
> the same object, and in multiprocess implementations (such as Chromium),
> they could be backed by different objects. This would not incur a runtime
> cost (and would be, subjectively of course, clearer).
>
> -Sam
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/5d089e27/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 26 May 2009 17:01:34 -0700
> From: Sam Weinig <sam.weinig at gmail.com>
> To: Drew Wilson <atwilson at google.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Notifications API
> Message-ID:
> <63a07bb10905261701w40adabf1v8298aac997de8541 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson <atwilson at google.com> wrote:
>
> > To give the list some insight into the discussions we've had with the
> > Chrome UX folks:
> >
> > 1) We want to associate some set of enhanced permissions with a given
> > origin (e.g. https://mail.yahoo.com), and we want the user to be
> presented
> > with a single "do you want to grant permissions to
> https://mail.yahoo.com"
> > dialog, rather peppering the user with a bunch of individual permission
> > dialogs for each feature ("Yes, please allow mail.yahoo.com to use 100MB
> > of local storage", "Yes, allow mail.yahoo.com to display notifications",
> > "Yes, allow mail.yahoo.com to run in the background").
>
>
> It seems like a bad idea to give all or nothing trust, and not along the
> lines of how APIs have managed choices in the past (quotas are increased
> when the limit is hit). I am not even sure how a UA would present such a
> choice to a user in a meaningful manner. I think a workflow such as the
> one
> quoted above by Maciej is a good direction, that gives a user a better
> chance of understanding the choice they are making.
>
>
> >
> > 2) We want the timing of the permission grant UI to be under application
> > control (as part of some kind of application user flow). So just visiting
> > mail.yahoo.com would not suddenly popup an unexpected dialog - instead
> the
> > application would have some UI along the lines of "Turn on desktop
> > notifications" which would drive some app-specific UI flow, a part of
> which
> > would involve the permission grant.
>
>
> Can you please elaborate on this, perhaps with a concrete example.
>
> -Sam
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/ed62b3e5/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 6
> Date: Tue, 26 May 2009 17:05:59 -0700
> From: Sam Weinig <sam.weinig at gmail.com>
> To: Jeremy Orlow <jorlow at chromium.org>
> Cc: Darin Adler <darin at apple.com>, WebKit Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <63a07bb10905261705n591047c2w66ff879a875653ed at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
> > The common case is definitely that we know whether we want the proxy (for
> > IPC) or the implementation at compile time. In some cases (like
> Chromium)
> > this is not known until initialization time.
>
>
> What do you mean by "initialization time"? Is it the case that you know
> which one you want at each call site? Or do literally want to make a
> runtime choice based on state?
>
> -Sam
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/18e574a6/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 7
> Date: Tue, 26 May 2009 17:21:13 -0700
> From: Jeremy Orlow <jorlow at chromium.org>
> To: Sam Weinig <sam.weinig at gmail.com>
> Cc: Darin Adler <darin at apple.com>, WebKit Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <5dd9e5c50905261721r3f24e265s452c677c29bb72c0 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>
> > On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at chromium.org>
> wrote:
> >
> >> The common case is definitely that we know whether we want the proxy
> (for
> >> IPC) or the implementation at compile time. In some cases (like
> Chromium)
> >> this is not known until initialization time.
> >
> >
> > What do you mean by "initialization time"? Is it the case that you know
> > which one you want at each call site? Or do literally want to make a
> > runtime choice based on state?
> >
>
> Well, I meant that we always want one or the other based on if the process
> is being used as a render process (i.e. sandboxed, running WebKit but with
> all DOM Storage calls proxied) or a browser process (i.e. running only
> selected parts of WebCore like the DOM Storage backend/implementation).
>
>
> Come to think of it (IIRC) all calls to the StorageBackend within the
> WebCore code should go through a proxy for Chromium. The proxy will then
> call into Chromium's webkit bridge/glue, which will pass the message
> through
> the IPC layer, which will call back into bridge/glue code, which will be
> interacting with the real implementation.
>
> If that's true, then the implementation could be very explicitly split into
> 2 (with frontend code calling backend proxy code and vice versa) and single
> process implementations could simply typedef _____Proxy to _____Impl (or
> Implementation, or Base, or whatever you want to call it).
>
> ....or have I completely confused myself?
>
> J
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/792611fe/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 8
> Date: Tue, 26 May 2009 17:31:52 -0700
> From: Jeremy Orlow <jorlow at chromium.org>
> To: Sam Weinig <sam.weinig at gmail.com>, Maciej Stachowiak
> <mjs at apple.com>, Drew Wilson <atwilson at google.com>, Darin
> Adler
> <darin at apple.com>, Michael Nordman <michaeln at google.com>, John
> Abd-El-Malek <jam at google.com>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <5dd9e5c50905261731o342870f3q79517f346c2500a5 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
> > On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.weinig at gmail.com>
> wrote:
> >
> >> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at chromium.org
> >wrote:
> >>
> >>> The common case is definitely that we know whether we want the proxy
> (for
> >>> IPC) or the implementation at compile time. In some cases (like
> Chromium)
> >>> this is not known until initialization time.
> >>
> >>
> >> What do you mean by "initialization time"? Is it the case that you
> know
> >> which one you want at each call site? Or do literally want to make a
> >> runtime choice based on state?
> >>
> >
> > Well, I meant that we always want one or the other based on if the
> process
> > is being used as a render process (i.e. sandboxed, running WebKit but
> with
> > all DOM Storage calls proxied) or a browser process (i.e. running only
> > selected parts of WebCore like the DOM Storage backend/implementation).
> >
> >
> > Come to think of it (IIRC) all calls to the StorageBackend within the
> > WebCore code should go through a proxy for Chromium. The proxy will then
> > call into Chromium's webkit bridge/glue, which will pass the message
> through
> > the IPC layer, which will call back into bridge/glue code, which will be
> > interacting with the real implementation.
> >
> > If that's true, then the implementation could be very explicitly split
> into
> > 2 (with frontend code calling backend proxy code and vice versa) and
> single
> > process implementations could simply typedef _____Proxy to _____Impl (or
> > Implementation, or Base, or whatever you want to call it).
> >
> > ....or have I completely confused myself?
> >
>
> To clarify, I'm saying that your question made me realize that we probably
> can make a hard split between the frontend and backend code (i.e. what
> would
> live in a sandbox and handle page rendering and what wouldn't live in a
> sand
> box and store the actual DOM Storage data). In single process cases where
> there is no IPC barrier, and thus no proxy (and thus the actual
> implementation code should be called directly) a typedef should bridge the
> 2
> with no run time performance penalty.
>
> Darin, Sam, Maciej: does this alleviate your concerns?
>
> Michael, Drew, John: do you think it'd work for workers/appcache as well?
>
> Everyone: have I completely missed something here?
>
> J
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/2ba7d7ea/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 9
> Date: Tue, 26 May 2009 18:02:53 -0700
> From: Michael Nordman <michaeln at google.com>
> To: Jeremy Orlow <jorlow at chromium.org>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>, Darin Adler
> <darin at apple.com>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <fa2eab050905261802k305a4aaaqa53e59a90ab6c1e2 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> > To clarify, I'm saying that your question made me realize that we
> probably
> > can make a hard split between the frontend and backend code (i.e. what
> would
> > live in a sandbox and handle page rendering and what wouldn't live in a
> sand
> > box and store the actual DOM Storage data).? In single process cases
> where
> > there is no IPC barrier, and thus no proxy (and thus the actual
> > implementation code should be called directly) a typedef should bridge
> the 2
> > with no run time performance penalty.
> >
> > Darin, Sam, Maciej: does this alleviate your concerns?
> >
> > Michael, Drew, John: do you think it'd work for workers/appcache as well?
>
> Partly.
>
> The split you just described is what I have in mind for the scripting
> related appcache interfaces. There always exists a hard split between
> front and back. The nature of the proxy is different depending. Btw, I
> also have in mind to use webcore's backend appache code in the
> seperate process (chrome's main process).
>
> The appcache is complicated by the fact that in addition to the
> scripting related interfaces, there are also interfaces around loading
> resources out of the cache. The loader currently calls into the
> appcache and wants an answer immediately (syncrhronously). These call
> happen at times not so friendly to remoting, like in advance of
> checking the memory cache... so I don't like the idea of injecting
> sync IPC calls at those times. I'm still wrestling with that part. I
> have in mind to overload ResourceHandle such that it knows how to load
> out of the appropiate appcache when needed, but what I haven't worked
> thru are how this plays well with webcore's memory cache.
>
>
> ------------------------------
>
> Message: 10
> Date: Tue, 26 May 2009 18:11:18 -0700
> From: Jeremy Orlow <jorlow at chromium.org>
> To: Michael Nordman <michaeln at google.com>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>, Darin Adler
> <darin at apple.com>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <5dd9e5c50905261811u292af381pa166627e0c04e377 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 6:02 PM, Michael Nordman <michaeln at google.com
> >wrote:
>
> > > To clarify, I'm saying that your question made me realize that we
> > probably
> > > can make a hard split between the frontend and backend code (i.e. what
> > would
> > > live in a sandbox and handle page rendering and what wouldn't live in a
> > sand
> > > box and store the actual DOM Storage data). In single process cases
> > where
> > > there is no IPC barrier, and thus no proxy (and thus the actual
> > > implementation code should be called directly) a typedef should bridge
> > the 2
> > > with no run time performance penalty.
> > >
> > > Darin, Sam, Maciej: does this alleviate your concerns?
> > >
> > > Michael, Drew, John: do you think it'd work for workers/appcache as
> well?
> >
> > Partly.
> >
> > The split you just described is what I have in mind for the scripting
> > related appcache interfaces. There always exists a hard split between
> > front and back. The nature of the proxy is different depending. Btw, I
> > also have in mind to use webcore's backend appache code in the
> > seperate process (chrome's main process).
> >
> > The appcache is complicated by the fact that in addition to the
> > scripting related interfaces, there are also interfaces around loading
> > resources out of the cache. The loader currently calls into the
> > appcache and wants an answer immediately (syncrhronously). These call
> > happen at times not so friendly to remoting, like in advance of
> > checking the memory cache... so I don't like the idea of injecting
> > sync IPC calls at those times. I'm still wrestling with that part. I
> > have in mind to overload ResourceHandle such that it knows how to load
> > out of the appropiate appcache when needed, but what I haven't worked
> > thru are how this plays well with webcore's memory cache.
>
>
> Did you say partly because it's more complicated than just splitting one
> class (and only having 1-way sync communication)? If so, then we're still
> on the same page, because that's what I'll be doing as well. I was just
> using the StorageBackend as an example, but events will require signals
> from
> the backend to the frontend, and some abstractions (like StorageArea) make
> a
> lot of sense whether or not things are split into two pieces, which sounds
> a
> lot like what you described with ResourceHandle.
>
> If not, what cases are there where you can't cleanly split things into the
> 2
> buckets: "call the proxy if it exists, otherwise call the implementation"
> and "ALWAYS call the implementation"
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/43f196dc/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 11
> Date: Tue, 26 May 2009 18:31:09 -0700
> From: Michael Nordman <michaeln at google.com>
> To: Jeremy Orlow <jorlow at chromium.org>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>, Darin Adler
> <darin at apple.com>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <fa2eab050905261831x34a688b0xa5a7481697521f82 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I think we're on the same page. What you described sounds good to me.
>
> I think ResourceHandle case is different because its involved in more
> than appcache specific stuff. In chrome the calls into the appcache
> while resource loading would occur on the chrome-side of the wire from
> chrome specific code (not from webcore). In the single-process model,
> the calls into the appcache would occur from webcore code.
>
>
> On Tue, May 26, 2009 at 6:11 PM, Jeremy Orlow<jorlow at chromium.org> wrote:
> > On Tue, May 26, 2009 at 6:02 PM, Michael Nordman <michaeln at google.com>
> > wrote:
> >>
> >> > To clarify, I'm saying that your question made me realize that we
> >> > probably
> >> > can make a hard split between the frontend and backend code (i.e. what
> >> > would
> >> > live in a sandbox and handle page rendering and what wouldn't live in
> a
> >> > sand
> >> > box and store the actual DOM Storage data).? In single process cases
> >> > where
> >> > there is no IPC barrier, and thus no proxy (and thus the actual
> >> > implementation code should be called directly) a typedef should bridge
> >> > the 2
> >> > with no run time performance penalty.
> >> >
> >> > Darin, Sam, Maciej: does this alleviate your concerns?
> >> >
> >> > Michael, Drew, John: do you think it'd work for workers/appcache as
> >> > well?
> >>
> >> Partly.
> >>
> >> The split you just described is what I have in mind for the scripting
> >> related appcache interfaces. There always exists a hard split between
> >> front and back. The nature of the proxy is different depending. Btw, I
> >> also have in mind to use webcore's backend appache code in the
> >> seperate process (chrome's main process).
> >>
> >> The appcache is complicated by the fact that in addition to the
> >> scripting related interfaces, there are also interfaces around loading
> >> resources out of the cache. The loader currently calls into the
> >> appcache and wants an answer immediately (syncrhronously). These call
> >> happen at times not so friendly to remoting, like in advance of
> >> checking the memory cache... so I don't like the idea of injecting
> >> sync IPC calls at those times. I'm still wrestling with that part. I
> >> have in mind to overload ResourceHandle such that it knows how to load
> >> out of the appropiate appcache when needed, but what I haven't worked
> >> thru are how this plays well with webcore's memory cache.
> >
> > Did you say partly because it's more complicated than just splitting one
> > class (and only having 1-way sync communication)?? If so, then we're
> still
> > on the same page, because that's what I'll be doing as well.? I was just
> > using the StorageBackend as an example, but events will require signals
> from
> > the backend to the frontend, and some abstractions (like StorageArea)
> make a
> > lot of sense whether or not things are split into two pieces, which
> sounds a
> > lot like what you described with ResourceHandle.
> >
> > If not, what cases are there where you can't cleanly split things into
> the 2
> > buckets: "call the proxy if it exists, otherwise call the implementation"
> > and "ALWAYS call the implementation"
> >
>
>
> ------------------------------
>
> Message: 12
> Date: Tue, 26 May 2009 18:32:05 -0700
> From: John Abd-El-Malek <jam at google.com>
> To: Sam Weinig <sam.weinig at gmail.com>
> Cc: Darin Adler <darin at apple.com>, WebKit Development
> <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <a06a97ee0905261832j1f7e5c9g25232eb05038cf0e at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 5:00 PM, Sam Weinig <sam.weinig at gmail.com> wrote:
>
> > On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek <jam at google.com
> >wrote:
> >
> >> I agree that this approach is powerful. However there are (not too
> >> frequent) situations when a port like Chromium wants to use both the
> WebKit
> >> implementation and its own implementation, switching in runtime. For
> >> workers, this happened with WorkerContextProxy/WorkerObjectProxy which
> are
> >> the interfaces that a worker object implements/uses. Since workers run
> in a
> >> separate process from the renderer, we use our own implementations of
> these
> >> interfaces that know about IPC etc. However once we're in the worker
> >> process, we want to run nested workers in the same process, in which
> case we
> >> want to use the WebKit implementation of these interfaces directly
> without
> >> using Chromium's.
> >
> >
> > This doesn't seem like a runtime choice, but rather a "use-time" choice.
> > In the main context, you want use one implementation and in the worker
> > context, another one. This to me implies two different objects with
> > different names.
> >
>
> The code that deals with these objects doesn't (and shouldn't) need to know
> the difference, i.e. there is only one set of JavaScript bindings for
> workers, regardless of which process they're being used in.
>
>
> > In non-multiprocess implementations of WebKit, these two objects could
> be
> > the same object, and in multiprocess implementations (such as Chromium),
> > they could be backed by different objects. This would not incur a
> runtime
> > cost (and would be, subjectively of course, clearer).
> >
> > -Sam
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/acd5beb6/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 13
> Date: Tue, 26 May 2009 19:00:37 -0700
> From: John Abd-El-Malek <jam at google.com>
> To: Jeremy Orlow <jorlow at chromium.org>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>, Darin Adler
> <darin at apple.com>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <a06a97ee0905261900p288247e9v36324f401438264a at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
> > On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <jorlow at chromium.org>
> wrote:
> >
> >> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.weinig at gmail.com>
> wrote:
> >>
> >>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at chromium.org
> >wrote:
> >>>
> >>>> The common case is definitely that we know whether we want the proxy
> >>>> (for IPC) or the implementation at compile time. In some cases (like
> >>>> Chromium) this is not known until initialization time.
> >>>
> >>>
> >>> What do you mean by "initialization time"? Is it the case that you
> know
> >>> which one you want at each call site? Or do literally want to make a
> >>> runtime choice based on state?
> >>>
> >>
> >> Well, I meant that we always want one or the other based on if the
> process
> >> is being used as a render process (i.e. sandboxed, running WebKit but
> with
> >> all DOM Storage calls proxied) or a browser process (i.e. running only
> >> selected parts of WebCore like the DOM Storage backend/implementation).
> >>
> >>
> >> Come to think of it (IIRC) all calls to the StorageBackend within the
> >> WebCore code should go through a proxy for Chromium. The proxy will
> then
> >> call into Chromium's webkit bridge/glue, which will pass the message
> through
> >> the IPC layer, which will call back into bridge/glue code, which will be
> >> interacting with the real implementation.
> >>
> >> If that's true, then the implementation could be very explicitly split
> >> into 2 (with frontend code calling backend proxy code and vice versa)
> and
> >> single process implementations could simply typedef _____Proxy to
> _____Impl
> >> (or Implementation, or Base, or whatever you want to call it).
> >>
> >> ....or have I completely confused myself?
> >>
> >
> > To clarify, I'm saying that your question made me realize that we
> probably
> > can make a hard split between the frontend and backend code (i.e. what
> would
> > live in a sandbox and handle page rendering and what wouldn't live in a
> sand
> > box and store the actual DOM Storage data). In single process cases
> where
> > there is no IPC barrier, and thus no proxy (and thus the actual
> > implementation code should be called directly) a typedef should bridge
> the 2
> > with no run time performance penalty.
> >
> > Darin, Sam, Maciej: does this alleviate your concerns?
> >
> > Michael, Drew, John: do you think it'd work for workers/appcache as well?
>
>
> This will work fine for appcache and localstorage, but isn't sufficient for
> workers since the same caller gets different objects depending on which
> process this is running in. This doesn't happen for appcache and
> localstorage.
>
>
> >
> >
> > Everyone: have I completely missed something here?
> >
> > J
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/493c76ca/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 14
> Date: Tue, 26 May 2009 19:23:04 -0700
> From: Jeremy Orlow <jorlow at chromium.org>
> To: John Abd-El-Malek <jam at google.com>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>, Darin Adler
> <darin at apple.com>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <5dd9e5c50905261923j4c7042d5xa8c0dafd295f59e9 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> It might also be worth bringing back up the unanswered quesiton of whether
> this is even worth it for AppCache and LocalStorage. As I mentioned, my
> (less than scientific) testing indicated no.* Maybe we're prematurely
> optimizing here? I definitely agree that virtual functions should be
> avoided in code that's often called, but even AppCache doesn't really seem
> to fit into that category.
>
> Jeremy
>
> * I have a test page that calls window.localStorage 100,000 times,
> localStorage.setItem(foo, bar) 100,000 times, and localStorage.getItem(foo)
> 1,000,000 times. All of these take under half a second, and the times
> don't
> really change with my new implementation which does use virtual dispatch.
>
>
> On Tue, May 26, 2009 at 7:00 PM, John Abd-El-Malek <jam at google.com> wrote:
>
> >
> >
> > On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow <jorlow at chromium.org>
> wrote:
> >
> >> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <jorlow at chromium.org
> >wrote:
> >>
> >>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.weinig at gmail.com
> >wrote:
> >>>
> >>>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at chromium.org
> >wrote:
> >>>>
> >>>>> The common case is definitely that we know whether we want the proxy
> >>>>> (for IPC) or the implementation at compile time. In some cases (like
> >>>>> Chromium) this is not known until initialization time.
> >>>>
> >>>>
> >>>> What do you mean by "initialization time"? Is it the case that you
> >>>> know which one you want at each call site? Or do literally want to
> make a
> >>>> runtime choice based on state?
> >>>>
> >>>
> >>> Well, I meant that we always want one or the other based on if the
> >>> process is being used as a render process (i.e. sandboxed, running
> WebKit
> >>> but with all DOM Storage calls proxied) or a browser process (i.e.
> running
> >>> only selected parts of WebCore like the DOM Storage
> backend/implementation).
> >>>
> >>>
> >>> Come to think of it (IIRC) all calls to the StorageBackend within the
> >>> WebCore code should go through a proxy for Chromium. The proxy will
> then
> >>> call into Chromium's webkit bridge/glue, which will pass the message
> through
> >>> the IPC layer, which will call back into bridge/glue code, which will
> be
> >>> interacting with the real implementation.
> >>>
> >>> If that's true, then the implementation could be very explicitly split
> >>> into 2 (with frontend code calling backend proxy code and vice versa)
> and
> >>> single process implementations could simply typedef _____Proxy to
> _____Impl
> >>> (or Implementation, or Base, or whatever you want to call it).
> >>>
> >>> ....or have I completely confused myself?
> >>>
> >>
> >> To clarify, I'm saying that your question made me realize that we
> probably
> >> can make a hard split between the frontend and backend code (i.e. what
> would
> >> live in a sandbox and handle page rendering and what wouldn't live in a
> sand
> >> box and store the actual DOM Storage data). In single process cases
> where
> >> there is no IPC barrier, and thus no proxy (and thus the actual
> >> implementation code should be called directly) a typedef should bridge
> the 2
> >> with no run time performance penalty.
> >>
> >> Darin, Sam, Maciej: does this alleviate your concerns?
> >>
> >> Michael, Drew, John: do you think it'd work for workers/appcache as
> well?
> >
> >
> > This will work fine for appcache and localstorage, but isn't sufficient
> for
> > workers since the same caller gets different objects depending on which
> > process this is running in. This doesn't happen for appcache and
> > localstorage.
> >
> >
> >>
> >>
> >> Everyone: have I completely missed something here?
> >>
> >> J
> >>
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/daa761ad/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 15
> Date: Tue, 26 May 2009 20:57:31 -0700
> From: Sam Weinig <sam.weinig at gmail.com>
> To: Drew Wilson <atwilson at google.com>
> Cc: webkit-dev at lists.webkit.org
> Subject: Re: [webkit-dev] Notifications API
> Message-ID:
> <63a07bb10905262057w5ff17952k64f330773033c818 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Tue, May 26, 2009 at 5:04 PM, Drew Wilson <atwilson at google.com> wrote:
>
> >
> >
> > On Tue, May 26, 2009 at 4:43 PM, Sam Weinig <sam.weinig at gmail.com>
> wrote:
> >
> >>
> >>
> >> On Tue, May 26, 2009 at 4:20 PM, Drew Wilson <atwilson at google.com>
> wrote:
> >>
> >>> To give the list some insight into the discussions we've had with the
> >>> Chrome UX folks:
> >>>
> >>> 1) We want to associate some set of enhanced permissions with a given
> >>> origin (e.g. https://mail.yahoo.com), and we want the user to be
> >>> presented with a single "do you want to grant permissions to
> >>> https://mail.yahoo.com" dialog, rather peppering the user with a bunch
> >>> of individual permission dialogs for each feature ("Yes, please allow
> >>> mail.yahoo.com to use 100MB of local storage", "Yes, allow
> >>> mail.yahoo.com to display notifications", "Yes, allow mail.yahoo.comto
> >>> run in the background").
> >>
> >>
> >> It seems like a bad idea to give all or nothing trust, and not along the
> >> lines of how APIs have managed choices in the past (quotas are increased
> >> when the limit is hit). I am not even sure how a UA would present such
> a
> >> choice to a user in a meaningful manner. I think a workflow such as the
> one
> >> quoted above by Maciej is a good direction, that gives a user a better
> >> chance of understanding the choice they are making.
> >>
> >
> > I thought that maciej suggested the same thing we suggested - an explicit
> > javascript API to request permissions. In our case, we want to ask for
> > permissions in bulk up front, rather than peppering the user with
> > permissions on an ad-hoc basis - in your example (prompting for more
> quota
> > when the quota is hit) will break things like background sync in
> persistent
> > workers, as the user may not be around when that background sync occurs.
> >
> >
>
> It is similar, but I am concerned with how to present a dialog to a user
> that states that by clicking "grant" they are completely trusting you.
>
>
> >
> >>
> >>>
> >>> 2) We want the timing of the permission grant UI to be under
> application
> >>> control (as part of some kind of application user flow). So just
> visiting
> >>> mail.yahoo.com would not suddenly popup an unexpected dialog - instead
> >>> the application would have some UI along the lines of "Turn on desktop
> >>> notifications" which would drive some app-specific UI flow, a part of
> which
> >>> would involve the permission grant.
> >>
> >>
> >> Can you please elaborate on this, perhaps with a concrete example.
> >>
> >
> > One example of a similar flow is Gmail Offline feature, where the user
> > clicks on a "Offline" link, which drives the user through some
> > app-controlled UI, culminating in a Gears permission-grant dialog. Here's
> > another example:
> >
> > Remember The Milk rolls out a new feature: desktop reminder
> notifications.
> > This is implemented by having a persistent worker which tracks changes on
> > the server, determines when it's appropriate to display a reminder for a
> > task, and displays a desktop notification.
> >
> > When a user logs into Remember The Milk, he sees a link: "New feature:
> > desktop reminders!". He clicks on this link, and is taken to an HTML page
> in
> > Remember The Milk which describes what the feature is and asks the user
> if
> > he wants to turn on these reminders. The application invokes getTrusted()
> to
> > see if the domain is already trusted - if it isn't, then the UI may
> include
> > some language to prepare the user for the upcoming permission grant
> dialog
> > by telling him what to expect.
> >
> > When the user clicks "yes, turn on this feature", the application calls
> > requestTrust() - this brings up the UserAgent-specific permission grant
> > dialog. When the user clicks the appropriate UI to grant this permission,
> > then the application has the ability to create persistent workers and
> > notifications (if we don't allow this kind of bulk permission grant, then
> > the user is subjected to multiple dialogs for each feature - persistent
> > workers and notifications - which is a crummy user experience).
> >
>
> I would argue it is much more confusing to a user to have to grant complete
> trust (for some undetermined list of things to trust a origin with).
> Should
> that include geolocation data? I don't really want Remember The Milk to
> know where I am, does that mean I can't have notifications? How can a user
> make an informed decision?
>
> -Sam
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/b0532b23/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 16
> Date: Tue, 26 May 2009 21:05:06 -0700
> From: David Levin <levin at chromium.org>
> To: Jeremy Orlow <jorlow at chromium.org>
> Cc: WebKit Development <webkit-dev at lists.webkit.org>
> Subject: Re: [webkit-dev] SharedWorkers alternate design
> Message-ID:
> <b902e34a0905262105n37be06cne044bb130e5b0595 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I think the principle is simple "classes that can avoid virtuals should."
> There are lots of tricky situations, but in general make a good effort to
> avoid virtual methods (which to me means be prepared to answer why you
> *need
> * a virtual method in a given place).
>
> By avoid them, there isn't a question of whether the virtuals are affecting
> performance (in any way -- making inlining impossible, adding to program
> size, messing with branch prediction, etc.)
> Sometimes great perf is due to one cool algorithm, but a lot of times it is
> also due to a thousand little things.
> dave
>
> On Tue, May 26, 2009 at 7:23 PM, Jeremy Orlow <jorlow at chromium.org> wrote:
>
> > It might also be worth bringing back up the unanswered quesiton of
> whether
> > this is even worth it for AppCache and LocalStorage. As I mentioned, my
> > (less than scientific) testing indicated no.* Maybe we're prematurely
> > optimizing here? I definitely agree that virtual functions should be
> > avoided in code that's often called, but even AppCache doesn't really
> seem
> > to fit into that category.
> >
> > Jeremy
> >
> > * I have a test page that calls window.localStorage 100,000 times,
> > localStorage.setItem(foo, bar) 100,000 times, and
> localStorage.getItem(foo)
> > 1,000,000 times. All of these take under half a second, and the times
> don't
> > really change with my new implementation which does use virtual dispatch.
> >
> >
> >
> > On Tue, May 26, 2009 at 7:00 PM, John Abd-El-Malek <jam at google.com>
> wrote:
> >
> >>
> >>
> >> On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow <jorlow at chromium.org
> >wrote:
> >>
> >>> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow <jorlow at chromium.org
> >wrote:
> >>>
> >>>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig <sam.weinig at gmail.com
> >wrote:
> >>>>
> >>>>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow <jorlow at chromium.org
> >wrote:
> >>>>>
> >>>>>> The common case is definitely that we know whether we want the proxy
> >>>>>> (for IPC) or the implementation at compile time. In some cases
> (like
> >>>>>> Chromium) this is not known until initialization time.
> >>>>>
> >>>>>
> >>>>> What do you mean by "initialization time"? Is it the case that you
> >>>>> know which one you want at each call site? Or do literally want to
> make a
> >>>>> runtime choice based on state?
> >>>>>
> >>>>
> >>>> Well, I meant that we always want one or the other based on if the
> >>>> process is being used as a render process (i.e. sandboxed, running
> WebKit
> >>>> but with all DOM Storage calls proxied) or a browser process (i.e.
> running
> >>>> only selected parts of WebCore like the DOM Storage
> backend/implementation).
> >>>>
> >>>>
> >>>> Come to think of it (IIRC) all calls to the StorageBackend within the
> >>>> WebCore code should go through a proxy for Chromium. The proxy will
> then
> >>>> call into Chromium's webkit bridge/glue, which will pass the message
> through
> >>>> the IPC layer, which will call back into bridge/glue code, which will
> be
> >>>> interacting with the real implementation.
> >>>>
> >>>> If that's true, then the implementation could be very explicitly split
> >>>> into 2 (with frontend code calling backend proxy code and vice versa)
> and
> >>>> single process implementations could simply typedef _____Proxy to
> _____Impl
> >>>> (or Implementation, or Base, or whatever you want to call it).
> >>>>
> >>>> ....or have I completely confused myself?
> >>>>
> >>>
> >>> To clarify, I'm saying that your question made me realize that we
> >>> probably can make a hard split between the frontend and backend code
> (i.e.
> >>> what would live in a sandbox and handle page rendering and what
> wouldn't
> >>> live in a sand box and store the actual DOM Storage data). In single
> >>> process cases where there is no IPC barrier, and thus no proxy (and
> thus the
> >>> actual implementation code should be called directly) a typedef should
> >>> bridge the 2 with no run time performance penalty.
> >>>
> >>> Darin, Sam, Maciej: does this alleviate your concerns?
> >>>
> >>> Michael, Drew, John: do you think it'd work for workers/appcache as
> well?
> >>
> >>
> >> This will work fine for appcache and localstorage, but isn't sufficient
> >> for workers since the same caller gets different objects depending on
> which
> >> process this is running in. This doesn't happen for appcache and
> >> localstorage.
> >>
> >>
> >>>
> >>>
> >>> Everyone: have I completely missed something here?
> >>>
> >>> J
> >>>
> >>
> >>
> >
> > _______________________________________________
> > webkit-dev mailing list
> > webkit-dev at lists.webkit.org
> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
> >
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.webkit.org/pipermail/webkit-dev/attachments/20090526/52b38f6e/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
>
> End of webkit-dev Digest, Vol 48, Issue 33
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090527/a9627c43/attachment-0001.html>
More information about the webkit-dev
mailing list