Re: [webkit-dev] SharedWorkers alternate design
> Having a dedicated shadow frame would be much simpler. Yup. I think this is required ultimately for appcache integration too. A shared worker is a distinct appcache host. Dedicated workers can get away with piggy backing of their owning document since they just use the same appcache as the page, but not shared workers. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
For SharedWorkers, the fallback is to select a document from the document set. It's slightly uglier, though, as I'd need to deal with the case where the user closes the document while we're trying to load via it. Having a dedicated shadow frame would be much simpler. -atw On Wed, Jun 17, 2009 at 7:03 PM, Dmitry Titov wrote: > I think there is still little clarity around the appcache behavior (dimich: >>> are you bring over your "shadow frame" concept to webkit?). >>> >> >> I'm wondering about bringing the 'shadow frame' technique to webcore too? >> > > If needs be :-) > > Just to explain what is meant by 'shadow frame' (I'm not sure it was > discussed in webkit-dev beore): to provide access to FrameLoader in Chrome's > Worker process (which loads WebKit but doesn't load any html, just creates a > worker out of JS string), we create a WebView and load it from a (url, > encoding, mimtype, data) source with empty data and the worker's url. This > creates a frame with a an empty document but with a right origin and > encoding. This makes it possible to create a ThreadableLoader (and > underlying DocumentThreadableLoader) w/o aceess to the original worker's > parent. This loader is used to implement XHR and importScripts in Chrome > workers. Oriinally a Darin Fisher's idea, it was implemented as alternative > to rollign out a new frame-less loader. > > Shared workers can use the same approach since they can not forever hold > the ref to the 'creating' document. > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
> > I think there is still little clarity around the appcache behavior (dimich: >> are you bring over your "shadow frame" concept to webkit?). >> > > I'm wondering about bringing the 'shadow frame' technique to webcore too? > If needs be :-) Just to explain what is meant by 'shadow frame' (I'm not sure it was discussed in webkit-dev beore): to provide access to FrameLoader in Chrome's Worker process (which loads WebKit but doesn't load any html, just creates a worker out of JS string), we create a WebView and load it from a (url, encoding, mimtype, data) source with empty data and the worker's url. This creates a frame with a an empty document but with a right origin and encoding. This makes it possible to create a ThreadableLoader (and underlying DocumentThreadableLoader) w/o aceess to the original worker's parent. This loader is used to implement XHR and importScripts in Chrome workers. Oriinally a Darin Fisher's idea, it was implemented as alternative to rollign out a new frame-less loader. Shared workers can use the same approach since they can not forever hold the ref to the 'creating' document. Dmitry ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Wed, Jun 17, 2009 at 3:43 PM, Drew Wilson wrote: > Following up again on this - now that my cross-thread MessagePort patch is > getting close to landing, I am moving forward on the SharedWorker design > described earlier in this thread. > I think there is still little clarity around the appcache behavior (dimich: > are you bring over your "shadow frame" concept to webkit?). > I think we're making decent progress, but integration with workers is a ways off yet. First things first for me, get things working w/o workers. I'm wondering about bringing the 'shadow frame' technique to webcore too? > > It doesn't seem like it should block the rest of SharedWorker development > while we work out the details - I will not expose the appcache APIs for > SharedWorkers until we have consensus about how they should work. > Sounds good. You should plow ahead without concern for appcache integration. I'll back fill later. We'll have similar backfilling to do with the Database too. > > > Let me know if you have any concerns with my approach. I'll add an > ENABLE_SHARED_WORKERS flag to control access to these APIs while development > proceeds. > > -atw > > > On Tue, Jun 2, 2009 at 11:43 AM, Michael Nordman wrote: > >> > As for our implementation - I don't know how appcache is integrated with >> the >> > loader code. >> >> We're still working out the details sans workers. But if it's a >> requirement to be able to a have an distinct "appache host" per shared >> worker, then so be it. >> >> > If not, we either need to add this support, or delay exposing appcache >> APIs to SharedWorkers >> > until we add the ability to load data from worker context without going >> through a document >> > object (probably required for persistent workers). >> >> I'm for deferring appcache + worker integration until we have appcach >> - worker integration in place (including in place for chrome). >> >> Exposing the scriptable APIs to workers don't necessarily have to go >> in lock step with and appcache selection and resource loading on >> behalf of workers. >> >> There may be some overlap with work being done to support resource >> loading for dedicated workers in chrome. In chrome resource loads >> don't go thru the renderer process at all (so no Document/Frame >> instances). I think Dmitry was talking about introducing a "FakeFrame" >> (maybe not the best name) for this purpose. >> > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
Following up again on this - now that my cross-thread MessagePort patch is getting close to landing, I am moving forward on the SharedWorker design described earlier in this thread. I think there is still little clarity around the appcache behavior (dimich: are you bring over your "shadow frame" concept to webkit?). It doesn't seem like it should block the rest of SharedWorker development while we work out the details - I will not expose the appcache APIs for SharedWorkers until we have consensus about how they should work. Let me know if you have any concerns with my approach. I'll add an ENABLE_SHARED_WORKERS flag to control access to these APIs while development proceeds. -atw On Tue, Jun 2, 2009 at 11:43 AM, Michael Nordman wrote: > > As for our implementation - I don't know how appcache is integrated with > the > > loader code. > > We're still working out the details sans workers. But if it's a > requirement to be able to a have an distinct "appache host" per shared > worker, then so be it. > > > If not, we either need to add this support, or delay exposing appcache > APIs to SharedWorkers > > until we add the ability to load data from worker context without going > through a document > > object (probably required for persistent workers). > > I'm for deferring appcache + worker integration until we have appcach > - worker integration in place (including in place for chrome). > > Exposing the scriptable APIs to workers don't necessarily have to go > in lock step with and appcache selection and resource loading on > behalf of workers. > > There may be some overlap with work being done to support resource > loading for dedicated workers in chrome. In chrome resource loads > don't go thru the renderer process at all (so no Document/Frame > instances). I think Dmitry was talking about introducing a "FakeFrame" > (maybe not the best name) for this purpose. > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
> As for our implementation - I don't know how appcache is integrated with the > loader code. We're still working out the details sans workers. But if it's a requirement to be able to a have an distinct "appache host" per shared worker, then so be it. > If not, we either need to add this support, or delay exposing appcache APIs > to SharedWorkers > until we add the ability to load data from worker context without going > through a document > object (probably required for persistent workers). I'm for deferring appcache + worker integration until we have appcach - worker integration in place (including in place for chrome). Exposing the scriptable APIs to workers don't necessarily have to go in lock step with and appcache selection and resource loading on behalf of workers. There may be some overlap with work being done to support resource loading for dedicated workers in chrome. In chrome resource loads don't go thru the renderer process at all (so no Document/Frame instances). I think Dmitry was talking about introducing a "FakeFrame" (maybe not the best name) for this purpose. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
> "the most appropriate app cache should be used" A little off topic... the spec says that in regard to appcache selection in general, its not specific to workers. That squishiness should probably be better defined at some point. 2009/6/2 Drew Wilson : > > Basically, the spec says "the most appropriate app cache should be used" > (which apparently we're free to interpret however we like), and that the > SharedWorker should have the ability to update its current app cache. I > think that the spec is fine. > As for our implementation - I don't know how appcache is integrated with the > loader code. Can I proxy a load to a given document, but still specify which > version of the app cache I want to use? If so, then we don't need to change > the > design. If not, we either need to add this support, or delay exposing appcache APIs to SharedWorkers until we add the ability to load data from worker context without going through a document object (probably required for persistent workers). > -atw > > 2009/6/2 Alexey Proskuryakov >> >> 02.06.2009, в 21:59, Michael Nordman написал(а): >> >>> Per the spec, shared workers are a distinct "browsing context". In >>> appcache terms, they have a distinct "appcache host". We have to come >>> up with a design that accomplishes that. >> >> >> OK, I was getting a feeling that we talked about different things. Andrew, >> do you agree that a different design is needed, or is this something we >> should push into the spec instead? >> >> - WBR, Alexey Proskuryakov >> >> > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
Basically, the spec says "the most appropriate app cache should be used" (which apparently we're free to interpret however we like), and that the SharedWorker should have the ability to update its current app cache. I think that the spec is fine. As for our implementation - I don't know how appcache is integrated with the loader code. Can I proxy a load to a given document, but still specify which version of the app cache I want to use? If so, then we don't need to change the design. If not, we either need to add this support, or delay exposing appcache APIs to SharedWorkers until we add the ability to load data from worker context without going through a document object (probably required for persistent workers). -atw 2009/6/2 Alexey Proskuryakov > > 02.06.2009, в 21:59, Michael Nordman написал(а): > > Per the spec, shared workers are a distinct "browsing context". In >> appcache terms, they have a distinct "appcache host". We have to come >> up with a design that accomplishes that. >> > > > OK, I was getting a feeling that we talked about different things. Andrew, > do you agree that a different design is needed, or is this something we > should push into the spec instead? > > - WBR, Alexey Proskuryakov > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 21:59, Michael Nordman написал(а): Per the spec, shared workers are a distinct "browsing context". In appcache terms, they have a distinct "appcache host". We have to come up with a design that accomplishes that. OK, I was getting a feeling that we talked about different things. Andrew, do you agree that a different design is needed, or is this something we should push into the spec instead? - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
2009/6/2 Alexey Proskuryakov : > > From Andrew's design document, I don't see how my description was > inaccurate: > > --- > Currently, all worker XHR requests are proxied to the parent page and > executed on the main thread. This approach currently works for dedicated > workers because there is a 1:1 mapping between dedicated workers and active > pages, and the worker is shutdown when the page closes. For SharedWorkers > (and for dedicated workers once we introduce nested workers) this is no > longer the case - the worker can outlive the parent page. > > To address this, we will use the DocumentSet for the worker. Worker XHR > requests will still be proxied to the main thread. This task will request > the DocumentSet from the repository, and select a document from that set to > use to satisfy the request. If the DocumentSet is empty, then it means that > the worker is shutting down, so the XHR should return a failure response. > --- > > From my reading of this, it appears that shared workers will use FrameLoader > of the opener page, or some other page in the DocumentSet, and won't get > their own loaders (that would be a feature of persistent workers, which we > aren't even discussing yet). This speaks specifically about XHR, but I > assumed that the same holds true for other network requests. That would be a design flaw... not a feature. All of this stuff about the DocumentSet associated with a shared worker is a hack to work around the problem of "how to load resource without a frame in webkit". Per the spec, shared workers are a distinct "browsing context". In appcache terms, they have a distinct "appcache host". We have to come up with a design that accomplishes that. > > - WBR, Alexey Proskuryakov > > > 02.06.2009, в 21:18, Michael Nordman написал(а): > >>> When a document calls a SharedWorker constructor, the worker script is >>> loaded from the document's >>> appcache (because all subresource loading goes through appcache, of >>> course). >> >> If I understand correctly, that is not what the spec currently says. >> >> Dedicated workers load as you describe, but not shared workers. The >> algorithm to determine what resource to load for a shared worker is >> the same as the algorithm used to determine what resource to load for >> a window.open(urlToPageWithoutAManifestAttributre) call. >> >> Personally, I think we should defer adding support for the appcache >> scriptable API to workers for the time being. But do support the >> resource loading / cache selection as currently specified. This would >> allow shared workers can be versioned independently (despite not >> having a good reload worker after an update story). >> >> These are shared workers. That implies a degree of separation from the >> pages that are sharing them. > > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
From Andrew's design document, I don't see how my description was inaccurate: --- Currently, all worker XHR requests are proxied to the parent page and executed on the main thread. This approach currently works for dedicated workers because there is a 1:1 mapping between dedicated workers and active pages, and the worker is shutdown when the page closes. For SharedWorkers (and for dedicated workers once we introduce nested workers) this is no longer the case - the worker can outlive the parent page. To address this, we will use the DocumentSet for the worker. Worker XHR requests will still be proxied to the main thread. This task will request the DocumentSet from the repository, and select a document from that set to use to satisfy the request. If the DocumentSet is empty, then it means that the worker is shutting down, so the XHR should return a failure response. --- From my reading of this, it appears that shared workers will use FrameLoader of the opener page, or some other page in the DocumentSet, and won't get their own loaders (that would be a feature of persistent workers, which we aren't even discussing yet). This speaks specifically about XHR, but I assumed that the same holds true for other network requests. - WBR, Alexey Proskuryakov 02.06.2009, в 21:18, Michael Nordman написал(а): When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 21:10, Drew Wilson написал(а): If worker global scope is actually a SharedWorkerGlobalScope object (i.e. the worker is a shared worker), and there are any relevant application caches that are identified by a manifest URL with the same origin as url and that have url as one of their entries, not excluding entries marked as foreign, then associate the worker global scope with themost appropriate application cache of those that match. I'm not at all certain what "most appropriate application cache" means, but I *think* it means "most up-to-date cache", not "cache associated with the constructing document". I think that's the point that this discussion hinges upon. Michael, do you know what that phrase means? There's a vague definition of "most appropriate" in the spec: Multiple application caches in different application cache groups can contain the same resource, e.g. if the manifests all reference that resource. If the user agent is to select an application cache from a list of relevant application caches that contain a resource, that the user agent must use the application cache that the user most likely wants to see the resource from, taking into account the following: • which application cache was most recently updated, • which application cache was being used to display the resource from which the user decided to look at the new resource, and • which application cache the user prefers. In current implementation, "most appropriate" is just "random", but the second test is what I think applies to SharedWorkers most closely. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
> When a document calls a SharedWorker constructor, the worker script is loaded > from the document's > appcache (because all subresource loading goes through appcache, of course). If I understand correctly, that is not what the spec currently says. Dedicated workers load as you describe, but not shared workers. The algorithm to determine what resource to load for a shared worker is the same as the algorithm used to determine what resource to load for a window.open(urlToPageWithoutAManifestAttributre) call. Personally, I think we should defer adding support for the appcache scriptable API to workers for the time being. But do support the resource loading / cache selection as currently specified. This would allow shared workers can be versioned independently (despite not having a good reload worker after an update story). These are shared workers. That implies a degree of separation from the pages that are sharing them. > But how is it a problem if we require SharedWorkers to implement a stable > messaging API? There are other interfaces to consider. The client<->server messaging interface used by the worker to talk to the mother ship. And more significantly, the localstorage schema used by the worker. Consider a "newer" version of a shared worker alters a local database schema. If an "older" version of the worker is pinned in some other appcache, that schema change is likely incompatible with the that older worker. 2009/6/1 Alexey Proskuryakov : > > 02.06.2009, в 1:29, Michael Nordman написал(а): > >>> What is the use case for this? It doesn't seem useful to me - to invoke >>> update explicitly, one >>> normally needs to have UI anyway, at which point it's much easier to call >>> update() directly from a >>> page. >> >> The use case are workers that can be considered "faceless >> applications". They are versioned independently of user interfaces >> that make use of them thru a stable message based API. > > > Is it really possible for a SharedWorker to be versioned independently from > UI? When a document calls a SharedWorker constructor, the worker script is > loaded from the document's appcache (because all subresource loading goes > through appcache, of course). So, its source always matches the UI version. > Even if there is a newer version of appcache already loaded, the document's > one will be used for loading subresources. > > When a worker's script is referenced from several appcaches, this becomes > somewhat trickier. As Andrew correctly mentioned, the version used will > depend on which application was the first to construct the SharedWorker. But > how is it a problem if we require SharedWorkers to implement a stable > messaging API? > > Given that SharedWorkers are versioned together with UI, and that loading a > new main resource in UI always invokes update process, I'm not sure if > there are any use cases that require workers to call update() on their own. > This is quite similar to how faceless helpers in large native application > suites work - I don't think that they ever check for updates, it's only done > at application startup. > > - WBR, Alexey Proskuryakov > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
2009/6/1 Alexey Proskuryakov > > 02.06.2009, в 1:29, Michael Nordman написал(а): > > What is the use case for this? It doesn't seem useful to me - to invoke >>> update explicitly, one >>> normally needs to have UI anyway, at which point it's much easier to call >>> update() directly from a >>> page. >>> >> >> The use case are workers that can be considered "faceless >> applications". They are versioned independently of user interfaces >> that make use of them thru a stable message based API. >> > > > Is it really possible for a SharedWorker to be versioned independently from > UI? When a document calls a SharedWorker constructor, the worker script is > loaded from the document's appcache (because all subresource loading goes > through appcache, of course). So, its source always matches the UI version. > Even if there is a newer version of appcache already loaded, the document's > one will be used for loading subresources. I don't think that's the intent of the spec: If worker global scope is actually a SharedWorkerGlobalScope<#sharedworkerglobalscope> object (i.e. the worker is a shared worker), and there are any relevant application caches that are identified by a manifest URL with the same origin as url and that have url as one of their entries, *not* excluding entries marked as foreign, then associate the worker global scope with themost appropriate application cache of those that match. I'm not at all certain what "most appropriate application cache" means, but I *think* it means "most up-to-date cache", not "cache associated with the constructing document". I think that's the point that this discussion hinges upon. Michael, do you know what that phrase means? I don't understand our AppCache implementation well enough to know how hard it will be to implement this behavior, given that we are proxying our loads to a parent document. -atw > > > When a worker's script is referenced from several appcaches, this becomes > somewhat trickier. As Andrew correctly mentioned, the version used will > depend on which application was the first to construct the SharedWorker. But > how is it a problem if we require SharedWorkers to implement a stable > messaging API? > > Given that SharedWorkers are versioned together with UI, and that loading a > new main resource in UI always invokes update process, I'm not sure if > there are any use cases that require workers to call update() on their own. > This is quite similar to how faceless helpers in large native application > suites work - I don't think that they ever check for updates, it's only done > at application startup. > > - WBR, Alexey Proskuryakov > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 0:19, Drew Wilson написал(а): My design doc just reflects the current spec - I don't really intend to be the defender of said spec. As I said previously, I think this is the wrong venue for us to describe issues with the spec - we should do it on the whatwg list to include other stakeholders. Did my response to Michael Nordman's message make the nature of objections more clear? I'd be happy to start that conversation on the whatwg list, but to be honest I don't think I'm quite understanding what your objections to the current spec are. Would you mind kicking off that discussion with whatwg, outlining your concerns? I think that there is value in discussing this among WebKit developers, as we can talk about how the design corresponds to low level implementation details. This is always important, but it would create a communication barrier on other venues. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
02.06.2009, в 1:29, Michael Nordman написал(а): What is the use case for this? It doesn't seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it's much easier to call update() directly from a page. The use case are workers that can be considered "faceless applications". They are versioned independently of user interfaces that make use of them thru a stable message based API. Is it really possible for a SharedWorker to be versioned independently from UI? When a document calls a SharedWorker constructor, the worker script is loaded from the document's appcache (because all subresource loading goes through appcache, of course). So, its source always matches the UI version. Even if there is a newer version of appcache already loaded, the document's one will be used for loading subresources. When a worker's script is referenced from several appcaches, this becomes somewhat trickier. As Andrew correctly mentioned, the version used will depend on which application was the first to construct the SharedWorker. But how is it a problem if we require SharedWorkers to implement a stable messaging API? Given that SharedWorkers are versioned together with UI, and that loading a new main resource in UI always invokes update process, I'm not sure if there are any use cases that require workers to call update() on their own. This is quite similar to how faceless helpers in large native application suites work - I don't think that they ever check for updates, it's only done at application startup. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
One more thing I'd follow up with is if we were to have a SharedWorker just inherit an applicationcache from the first document that creates it, what happens after that document closes? How can the SharedWorker update its application cache if an update becomes available, since the only document associated with that cache is now closed? -atw 2009/6/1 Michael Nordman > How workers and appcaches interact has been discussed on the WHATWG > list. Ian's "Worker feedback" message on 3/27/09 tried to tie things > up for the time being. I think where he left things was a reasonable > stepping stone, although the answers to the questions being asked here > about updates were not entirely resolved. > > > What is the use case for this? It doesn't seem useful to me - to invoke > update explicitly, one > > normally needs to have UI anyway, at which point it's much easier to call > update() directly from a > > page. > > The use case are workers that can be considered "faceless > applications". They are versioned independently of user interfaces > that make use of them thru a stable message based API. > > > A tangentially related question: what will happen to a SharedWorker whose > cache got updated? > > Will the repository use a new source for new instances, while the old > ones will continue to run? > > I think the intent of the current spec is that a new instance would > not be created provided there is an existing instance already running. > How to reload an existing worker to utilize new resources in an > updated cache was left as an exercise to the reader. > > At least that's my understanding of the current spec. > > > 2009/6/1 Drew Wilson : > > > > > > 2009/6/1 Alexey Proskuryakov > >> > >> 01.06.2009, в 22:37, Drew Wilson написал(а): > >> > >> 1) Since SharedWorkers aren't explicitly tied to a specific Document, it > >> doesn't make sense to have them possibly get loaded from an out-of-date > >> version of the app cache. If you have two separate documents running > from > >> different caches, it's weird (and indeterminate) if the version of the > cache > >> used to load the SharedWorker script is dependent on which one happens > to > >> call "new SharedWorker()" first. > >> > >> I don't see how exposing DOMApplicationCache methods to workers can help > >> this - a worker will only be able to call DOMApplicationCache.update() > >> after it has started, which is too late. > > > > Not sure why that is "too late"? Can you clarify? > > > >> > >> Besides, won't the document using an old version of cache break if a > newer > >> SharedWorker is suddenly returned to it? The main idea of appcache is > that > >> all application resources are versioned, so if we see SharedWorkers as > part > >> of application, they should use the same cache version. And if they are > >> independent entities with a stable API, using an out of date version for > a > >> while cannot hurt. > > > > Why would a document using an old version of cache break if a newer > > SharedWorker is returned? Why is that any more of a problem than a > document > > using a new version of cache breaking if an older SharedWorker is > returned, > > which is what would happen if SharedWorkers inherited appcache from the > > first document that instantiated them? > > It seems like there are several easy options available to apps: > > 1) Change the name of the shared worker if a non-backward-compatible > change > > needs to be made to the worker script (so new documents don't share the > same > > worker instance as old documents) > > 2) When updates are available, coordinate updates with all documents so > > everyone updates at once, possibly exiting the SharedWorker. > > > >> > >> As for what happens to a SharedWorker whose cache was updated? My > >> presumption is that all future resource loads would use that cache. At > that > >> point, the SharedWorker has a few different things it could do: > >> > >> Reload all of its scripts again using importScripts(). This implies that > >> its script loading is idempotent, but that's not too hard to do. > >> Send messages to all of its client documents letting it know that it is > >> shutting down, then invoke close() to shut itself down. The client > documents > >> can re-create the SharedWorker the next time they want one. This is > >> inherently race-y, though, since you can't easily coordinate the > shutdown of > >> the worker with instantiations of new ones. > >> Do nothing at all > >> > >> All of these options seem quite dangerous - it may be difficult for JS > >> authors to write applications that won't break at update time. > > > > It might be tricky, although any application that does dynamic JS loading > > has to deal with versioning issues already. This is not particularly > > different. > > > >> > >> > >> > >> A document can reload itself after updating, but SharedWorkers do not > have > >> a way to reload themselves. As you mentioned, they can reload imported > >> scripts (but the main script will remain the
Re: [webkit-dev] SharedWorkers alternate design
How workers and appcaches interact has been discussed on the WHATWG list. Ian's "Worker feedback" message on 3/27/09 tried to tie things up for the time being. I think where he left things was a reasonable stepping stone, although the answers to the questions being asked here about updates were not entirely resolved. > What is the use case for this? It doesn't seem useful to me - to invoke > update explicitly, one > normally needs to have UI anyway, at which point it's much easier to call > update() directly from a > page. The use case are workers that can be considered "faceless applications". They are versioned independently of user interfaces that make use of them thru a stable message based API. > A tangentially related question: what will happen to a SharedWorker whose > cache got updated? > Will the repository use a new source for new instances, while the old ones > will continue to run? I think the intent of the current spec is that a new instance would not be created provided there is an existing instance already running. How to reload an existing worker to utilize new resources in an updated cache was left as an exercise to the reader. At least that's my understanding of the current spec. 2009/6/1 Drew Wilson : > > > 2009/6/1 Alexey Proskuryakov >> >> 01.06.2009, в 22:37, Drew Wilson написал(а): >> >> 1) Since SharedWorkers aren't explicitly tied to a specific Document, it >> doesn't make sense to have them possibly get loaded from an out-of-date >> version of the app cache. If you have two separate documents running from >> different caches, it's weird (and indeterminate) if the version of the cache >> used to load the SharedWorker script is dependent on which one happens to >> call "new SharedWorker()" first. >> >> I don't see how exposing DOMApplicationCache methods to workers can help >> this - a worker will only be able to call DOMApplicationCache.update() >> after it has started, which is too late. > > Not sure why that is "too late"? Can you clarify? > >> >> Besides, won't the document using an old version of cache break if a newer >> SharedWorker is suddenly returned to it? The main idea of appcache is that >> all application resources are versioned, so if we see SharedWorkers as part >> of application, they should use the same cache version. And if they are >> independent entities with a stable API, using an out of date version for a >> while cannot hurt. > > Why would a document using an old version of cache break if a newer > SharedWorker is returned? Why is that any more of a problem than a document > using a new version of cache breaking if an older SharedWorker is returned, > which is what would happen if SharedWorkers inherited appcache from the > first document that instantiated them? > It seems like there are several easy options available to apps: > 1) Change the name of the shared worker if a non-backward-compatible change > needs to be made to the worker script (so new documents don't share the same > worker instance as old documents) > 2) When updates are available, coordinate updates with all documents so > everyone updates at once, possibly exiting the SharedWorker. > >> >> As for what happens to a SharedWorker whose cache was updated? My >> presumption is that all future resource loads would use that cache. At that >> point, the SharedWorker has a few different things it could do: >> >> Reload all of its scripts again using importScripts(). This implies that >> its script loading is idempotent, but that's not too hard to do. >> Send messages to all of its client documents letting it know that it is >> shutting down, then invoke close() to shut itself down. The client documents >> can re-create the SharedWorker the next time they want one. This is >> inherently race-y, though, since you can't easily coordinate the shutdown of >> the worker with instantiations of new ones. >> Do nothing at all >> >> All of these options seem quite dangerous - it may be difficult for JS >> authors to write applications that won't break at update time. > > It might be tricky, although any application that does dynamic JS loading > has to deal with versioning issues already. This is not particularly > different. > >> >> >> >> A document can reload itself after updating, but SharedWorkers do not have >> a way to reload themselves. As you mentioned, they can reload imported >> scripts (but the main script will remain the same, which would be >> inconsistent). > > Why can't they reload the main script? Again, there's a need to be > idempotent if you need to maintain some cached state, but it's not totally > impossible. > >> >> Or they can shut down and ask a document to re-create themselves - at >> which point, we can as well say that the document can update the cache. > > I'm not arguing against this, I just don't see how it works when you have > multiple documents each of which are running from different versions of the > app cache, where the shared worker itself is attached to some
Re: [webkit-dev] SharedWorkers alternate design
2009/6/1 Alexey Proskuryakov > > 01.06.2009, в 22:37, Drew Wilson написал(а): > > 1) Since SharedWorkers aren't explicitly tied to a specific Document, it > doesn't make sense to have them possibly get loaded from an out-of-date > version of the app cache. If you have two separate documents running from > different caches, it's weird (and indeterminate) if the version of the cache > used to load the SharedWorker script is dependent on which one happens to > call "new SharedWorker()" first. > > > I don't see how exposing DOMApplicationCache methods to workers can help > this - a worker will only be able to call DOMApplicationCache.update() > after it has started, which is too late. > Not sure why that is "too late"? Can you clarify? > > Besides, won't the document using an old version of cache break if a newer > SharedWorker is suddenly returned to it? The main idea of appcache is that > all application resources are versioned, so if we see SharedWorkers as part > of application, they should use the same cache version. And if they are > independent entities with a stable API, using an out of date version for a > while cannot hurt. > > Why would a document using an old version of cache break if a newer SharedWorker is returned? Why is that any more of a problem than a document using a new version of cache breaking if an older SharedWorker is returned, which is what would happen if SharedWorkers inherited appcache from the first document that instantiated them? It seems like there are several easy options available to apps: 1) Change the name of the shared worker if a non-backward-compatible change needs to be made to the worker script (so new documents don't share the same worker instance as old documents) 2) When updates are available, coordinate updates with all documents so everyone updates at once, possibly exiting the SharedWorker. > > As for what happens to a SharedWorker whose cache was updated? My > presumption is that all future resource loads would use that cache. At that > point, the SharedWorker has a few different things it could do: > >- Reload all of its scripts again using importScripts(). This implies >that its script loading is idempotent, but that's not too hard to do. >- Send messages to all of its client documents letting it know that it >is shutting down, then invoke close() to shut itself down. The client >documents can re-create the SharedWorker the next time they want one. This >is inherently race-y, though, since you can't easily coordinate the > shutdown >of the worker with instantiations of new ones. >- Do nothing at all > > All of these options seem quite dangerous - it may be difficult for JS > authors to write applications that won't break at update time. > It might be tricky, although any application that does dynamic JS loading has to deal with versioning issues already. This is not particularly different. > > > A document can reload itself after updating, but SharedWorkers do not have > a way to reload themselves. As you mentioned, they can reload imported > scripts (but the main script will remain the same, which would be > inconsistent). > Why can't they reload the main script? Again, there's a need to be idempotent if you need to maintain some cached state, but it's not totally impossible. > Or they can shut down and ask a document to re-create themselves - at which > point, we can as well say that the document can update the cache. > I'm not arguing against this, I just don't see how it works when you have multiple documents each of which are running from different versions of the app cache, where the shared worker itself is attached to some arbitrary instance. > > Interaction of SharedWorkers and appcache, explicit or not, sounds like a > major issue to me. It can significantly affect the design (or even make > SharedWorkers not worth being added, if no acceptable solution is found). > My design doc just reflects the current spec - I don't really intend to be the defender of said spec. As I said previously, I think this is the wrong venue for us to describe issues with the spec - we should do it on the whatwg list to include other stakeholders. I'd be happy to start that conversation on the whatwg list, but to be honest I don't think I'm quite understanding what your objections to the current spec are. Would you mind kicking off that discussion with whatwg, outlining your concerns? -atw ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
01.06.2009, в 22:37, Drew Wilson написал(а): 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call "new SharedWorker()" first. I don't see how exposing DOMApplicationCache methods to workers can help this - a worker will only be able to call DOMApplicationCache.update() after it has started, which is too late. Besides, won't the document using an old version of cache break if a newer SharedWorker is suddenly returned to it? The main idea of appcache is that all application resources are versioned, so if we see SharedWorkers as part of application, they should use the same cache version. And if they are independent entities with a stable API, using an out of date version for a while cannot hurt. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. Do nothing at all All of these options seem quite dangerous - it may be difficult for JS authors to write applications that won't break at update time. A document can reload itself after updating, but SharedWorkers do not have a way to reload themselves. As you mentioned, they can reload imported scripts (but the main script will remain the same, which would be inconsistent). Or they can shut down and ask a document to re- create themselves - at which point, we can as well say that the document can update the cache. Interaction of SharedWorkers and appcache, explicit or not, sounds like a major issue to me. It can significantly affect the design (or even make SharedWorkers not worth being added, if no acceptable solution is found). - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
We should probably discuss this point on the whatwg list, but I'll give you my understanding of why this is desirable: 1) Since SharedWorkers aren't explicitly tied to a specific Document, it doesn't make sense to have them possibly get loaded from an out-of-date version of the app cache. If you have two separate documents running from different caches, it's weird (and indeterminate) if the version of the cache used to load the SharedWorker script is dependent on which one happens to call "new SharedWorker()" first. 2) Since SharedWorkers may outlive a given document, it makes sense to allow them to manage their own appcache state, especially once we start supporting PersistentWorkers (which may run for days, weeks, or years). 3) SharedWorkers may have a different criteria determining when it wants to update its app cache. As for what happens to a SharedWorker whose cache was updated? My presumption is that all future resource loads would use that cache. At that point, the SharedWorker has a few different things it could do: - Reload all of its scripts again using importScripts(). This implies that its script loading is idempotent, but that's not too hard to do. - Send messages to all of its client documents letting it know that it is shutting down, then invoke close() to shut itself down. The client documents can re-create the SharedWorker the next time they want one. This is inherently race-y, though, since you can't easily coordinate the shutdown of the worker with instantiations of new ones. - Do nothing at all -atw 2009/6/1 Alexey Proskuryakov > > 22.05.2009, в 3:20, Drew Wilson написал(а): > > >- SharedWorkers have explicit access to the ApplicationCache APIs, >while dedicated Workers merely inherit the ApplicationCache from their >parent window. > > What is the use case for this? It doesn't seem useful to me - to invoke > update explicitly, one normally needs to have UI anyway, at which point it's > much easier to call update() directly from a page. > > A tangentially related question: what will happen to a SharedWorker whose > cache got updated? Will the repository use a new source for new instances, > while the old ones will continue to run? Looks like there is a significant > potential for mistakes here, as scripts won't normally expect several > instances of the same SharedWorker to be active. > > - WBR, Alexey Proskuryakov > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
22.05.2009, в 3:20, Drew Wilson написал(а): SharedWorkers have explicit access to the ApplicationCache APIs, while dedicated Workers merely inherit the ApplicationCache from their parent window. What is the use case for this? It doesn't seem useful to me - to invoke update explicitly, one normally needs to have UI anyway, at which point it's much easier to call update() directly from a page. A tangentially related question: what will happen to a SharedWorker whose cache got updated? Will the repository use a new source for new instances, while the old ones will continue to run? Looks like there is a significant potential for mistakes here, as scripts won't normally expect several instances of the same SharedWorker to be active. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
> Can you think of a more specific way to describe the reationship than > "front" and "back" or "client" and "service"? Does one of the Gang of Four > Design Patterns apply? That can be a good resource for clear ways to > describe class relationships, even fairly abstract ones. Nice suggestion... In my case Facade may be the most appropriate name for what i've been referring to as the 'frontend' interface. I'm endeavoring to provide a simplified interface (a facade) to a more complex system, the moving parts of which are not important to clients of the facade. Inside that Facade, Proxy may be the most appropriate for the messaging abstraction parts. ApplicationCacheFacade * uses ApplicationCacheSystemProxy ApplicationCacheSystem * uses ApplicationCacheFacadeProxy WDYT? ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On May 28, 2009, at 3:14 PM, Michael Nordman wrote: Doesn't sound like we have a consensus on naming yet? Many of the suggestions are workable to me. FooClient | FooFrontend | FooIntf | FooConsumer FooService | FooBackend | FooImpl | FooProvider I have a patch that is employing FooFrontend + FooBackend naming... i'd be happy to change to something else... or not. I don't like 'proxy' to indicate one side or the other, because as Jeremy said it doesn't indicate which side, there are proxies on both sides to communicate with the other. My top two picks... 1) FooFrontend + FooBackend 2) FooClient + FooService Can you think of a more specific way to describe the reationship than "front" and "back" or "client" and "service"? Does one of the Gang of Four Design Patterns apply? That can be a good resource for clear ways to describe class relationships, even fairly abstract ones. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
> I think it was pretty clear from the thread that X and XClient is prefered > when you have 2 way communication. In some cases, you have X which is the > interface, XImpl which is the implementation, and XProxy for a proxy. > > But yeahI think Foo and FooClient is the way to go with Impl and Proxy > if you need to have 2 versions of each (which I think you do). In my case, I want to reserve the name ApplicationCache for an object that contains a collection of entries which lives strincly in the 'backend'. So i guess that leave me with for following for the front/back splitting related things... ApplicationCacheClient// for the 'frontend' ApplicationCacheServiceProxy // for the front to talk to the back ApplicationCacheService // for the 'backend' ApplicationCacheClientProxy // for the back to talk to the front which works for me just fine. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
I think it was pretty clear from the thread that X and XClient is prefered when you have 2 way communication. In some cases, you have X which is the interface, XImpl which is the implementation, and XProxy for a proxy. But yeahI think Foo and FooClient is the way to go with Impl and Proxy if you need to have 2 versions of each (which I think you do). J On Thu, May 28, 2009 at 3:14 PM, Michael Nordman wrote: > Doesn't sound like we have a consensus on naming yet? Many of the > suggestions are workable to me. > > FooClient | FooFrontend | FooIntf | FooConsumer > FooService | FooBackend | FooImpl | FooProvider > > I have a patch that is employing FooFrontend + FooBackend naming... > i'd be happy to change to something else... or not. > > I don't like 'proxy' to indicate one side or the other, because as > Jeremy said it doesn't indicate which side, there are proxies on both > sides to communicate with the other. > > My top two picks... > 1) FooFrontend + FooBackend > 2) FooClient + FooService > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
Doesn't sound like we have a consensus on naming yet? Many of the suggestions are workable to me. FooClient | FooFrontend | FooIntf | FooConsumer FooService | FooBackend | FooImpl | FooProvider I have a patch that is employing FooFrontend + FooBackend naming... i'd be happy to change to something else... or not. I don't like 'proxy' to indicate one side or the other, because as Jeremy said it doesn't indicate which side, there are proxies on both sides to communicate with the other. My top two picks... 1) FooFrontend + FooBackend 2) FooClient + FooService ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Wed, May 27, 2009 at 3:37 PM, John Abd-El-Malek wrote: > > > On Wed, May 27, 2009 at 12:00 AM, Jeremy Orlow wrote: > >> On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak wrote: >> >>> >>> On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote: >>> >>> 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. >>> >>> As a side note - I think it would be cool if we used more specific names >>> than "Backend" and "Frontened" in the actual code, since which end is front >>> and back is not always obvious nor always agreed upon by all observers. I >>> like Proxy and Impl ok as name pairs, not sure if that's the same >>> relationship you have in mind. >> >> >> I somewhat disagree regarding the terms frontend and backend being >> confusing. It seems to me that the backend is always further away from the >> user than the frontend. Same thing with client and server. That said, I've >> definitely heard complaints about terms like this before (on other >> projects), so I'm not married to the terms. >> >> The names I was planning to use were outlined in a design doc I sent to >> this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m). >> Basically, I was planning to the term Backend, but the rest of the names >> are more descriptive. If you have another suggestion for Backend, I'd be >> happy to change it. I would have already, but the only other idea I had was >> server, and I think people find that term even more confusing. >> StorageRepository might be an ok name. >> >> As for Impl and Proxy, they are actually somewhat orthogonal to the >> frontend and backend. For example, if a script calls >> window.localStorage.setItem(foo, bar), the frontend in the render process >> will access the backend proxy which will send the message to the browser >> process where the backend implementation lives. The backend implementation >> will then access the EventManagerProxy which will distribute the events to >> the EventManagerImpl in all the render processes. In other words, Proxies >> are necessary anywhere messages originate. >> > > Just as a data point: Chrome uses Proxy/Impl naming for a variety of > classes (i.e. WebWorkerProxy/WebWorkerImpl, > WebWorkerClientProxy/WebWorkerClientImpl, WebPluginProxy/WebPluginImpl, > WebPluginDelegateProxy/WebPluginDelegateImpl). The code is also moving to X > and XClient for the two-way API for feature X. If possible, it would be > good to match these names for the sake of consistency. > > How about: > > StorageImpl (lives in the process that opens the database) > StorageProxy (in multi-process browser, lives in the renderer process and > notifies above) > > StorageClientImpl (receives event that value changed) > StorageClientProxy (in multi-process browser, lives in the browser process > and notifies above) > Thanks for the pointers and suggestions. Unfortunately, in my experience, the distinction between client/server is even more confusing to developers than frontend/backend. In addition, the XClient naming scheme doesn't really fit into the design I've currently got in mind (which was documented in the design doc I've sent out a couple times) since there are a couple different classes that compose the frontend. So I'm not sure it'll really fit into my design here. J ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Wed, May 27, 2009 at 12:00 AM, Jeremy Orlow wrote: > On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak wrote: > >> >> On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote: >> >> >>> 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. >>> >> >> As a side note - I think it would be cool if we used more specific names >> than "Backend" and "Frontened" in the actual code, since which end is front >> and back is not always obvious nor always agreed upon by all observers. I >> like Proxy and Impl ok as name pairs, not sure if that's the same >> relationship you have in mind. > > > I somewhat disagree regarding the terms frontend and backend being > confusing. It seems to me that the backend is always further away from the > user than the frontend. Same thing with client and server. That said, I've > definitely heard complaints about terms like this before (on other > projects), so I'm not married to the terms. > > The names I was planning to use were outlined in a design doc I sent to > this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m). Basically, > I was planning to the term Backend, but the rest of the names are more > descriptive. If you have another suggestion for Backend, I'd be happy to > change it. I would have already, but the only other idea I had was server, > and I think people find that term even more confusing. StorageRepository > might be an ok name. > > As for Impl and Proxy, they are actually somewhat orthogonal to the > frontend and backend. For example, if a script calls > window.localStorage.setItem(foo, bar), the frontend in the render process > will access the backend proxy which will send the message to the browser > process where the backend implementation lives. The backend implementation > will then access the EventManagerProxy which will distribute the events to > the EventManagerImpl in all the render processes. In other words, Proxies > are necessary anywhere messages originate. > Just as a data point: Chrome uses Proxy/Impl naming for a variety of classes (i.e. WebWorkerProxy/WebWorkerImpl, WebWorkerClientProxy/WebWorkerClientImpl, WebPluginProxy/WebPluginImpl, WebPluginDelegateProxy/WebPluginDelegateImpl). The code is also moving to X and XClient for the two-way API for feature X. If possible, it would be good to match these names for the sake of consistency. How about: StorageImpl (lives in the process that opens the database) StorageProxy (in multi-process browser, lives in the renderer process and notifies above) StorageClientImpl (receives event that value changed) StorageClientProxy (in multi-process browser, lives in the browser process and notifies above) > > Jeremy > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
> P.S. I hope all this design input isn't being too fussy. Working on a big > project like WebKit is a constant battle against entropy, and we try hard to > find good patterns and spread them as a counter. But I don't mean to make a > huge deal out of this naming detail. Thanx for the input, very much appreciate the passing along of design sensibilities prevalent in the project. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On May 27, 2009, at 12:00 AM, Jeremy Orlow wrote: On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak wrote: On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote: 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. As a side note - I think it would be cool if we used more specific names than "Backend" and "Frontened" in the actual code, since which end is front and back is not always obvious nor always agreed upon by all observers. I like Proxy and Impl ok as name pairs, not sure if that's the same relationship you have in mind. I somewhat disagree regarding the terms frontend and backend being confusing. It seems to me that the backend is always further away from the user than the frontend. An example of why I think these terms can be confusing: Which part of the style system would you guess is traditionally described as the "back end"? Hint: it's not the part further from the user. I'm glad we call it RenderStyle instead of StyleBackEnd in the code. Same thing with client and server. That said, I've definitely heard complaints about terms like this before (on other projects), so I'm not married to the terms. The names I was planning to use were outlined in a design doc I sent to this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m). Basically, I was planning to the term Backend, but the rest of the names are more descriptive. If you have another suggestion for Backend, I'd be happy to change it. I would have already, but the only other idea I had was server, and I think people find that term even more confusing. StorageRepository might be an ok name. Something like StorageRepository or StorageDataStore (despite the repetition) might be good. I haven't thought deeply about specific uses of "back end", but it's definitely something I am allergic to in general, as stated above. As for Impl and Proxy, they are actually somewhat orthogonal to the frontend and backend. For example, if a script calls window.localStorage.setItem(foo, bar), the frontend in the render process will access the backend proxy which will send the message to the browser process where the backend implementation lives. The backend implementation will then access the EventManagerProxy which will distribute the events to the EventManagerImpl in all the render processes. In other words, Proxies are necessary anywhere messages originate. Thanks for clarifying. Regards, Maciej P.S. I hope all this design input isn't being too fussy. Working on a big project like WebKit is a constant battle against entropy, and we try hard to find good patterns and spread them as a counter. But I don't mean to make a huge deal out of this naming detail. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 9:42 PM, Maciej Stachowiak wrote: > > On May 26, 2009, at 7:00 PM, John Abd-El-Malek wrote: > > >> 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. >> >> > It's fine to use virtual methods when you actually need runtime > polymorphism at the same call site. The point is not to tie yourself in a > knot if there really is true polymorphism, just to avoid paying runtime > penalties for anything that can actually be a compile-time decision. If it > can't be, then so be it. Sounds good. I was a bit worried that we were needlessly adding a lot of complexity to the code, but you're definitely right that slow performance can be a "death by a thousand cuts" type thing. I'll give it a shot for DOM Storage, but it sounds like workers will need to still use polymorphism. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak wrote: > > On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote: > > >> 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. >> > > As a side note - I think it would be cool if we used more specific names > than "Backend" and "Frontened" in the actual code, since which end is front > and back is not always obvious nor always agreed upon by all observers. I > like Proxy and Impl ok as name pairs, not sure if that's the same > relationship you have in mind. I somewhat disagree regarding the terms frontend and backend being confusing. It seems to me that the backend is always further away from the user than the frontend. Same thing with client and server. That said, I've definitely heard complaints about terms like this before (on other projects), so I'm not married to the terms. The names I was planning to use were outlined in a design doc I sent to this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m). Basically, I was planning to the term Backend, but the rest of the names are more descriptive. If you have another suggestion for Backend, I'd be happy to change it. I would have already, but the only other idea I had was server, and I think people find that term even more confusing. StorageRepository might be an ok name. As for Impl and Proxy, they are actually somewhat orthogonal to the frontend and backend. For example, if a script calls window.localStorage.setItem(foo, bar), the frontend in the render process will access the backend proxy which will send the message to the browser process where the backend implementation lives. The backend implementation will then access the EventManagerProxy which will distribute the events to the EventManagerImpl in all the render processes. In other words, Proxies are necessary anywhere messages originate. Jeremy ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On May 26, 2009, at 9:05 PM, David Levin wrote: 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. Indeed, and we try to do the thousands of little things when we can find a practical pattern that enables us to do so. PassRefPtr is an example of this; there is probably no one call site where avoiding refcount thrash matters, but spread throughout the whole code base, it adds up to a measurable improvement. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On May 26, 2009, at 7:00 PM, John Abd-El-Malek wrote: 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. It's fine to use virtual methods when you actually need runtime polymorphism at the same call site. The point is not to tie yourself in a knot if there really is true polymorphism, just to avoid paying runtime penalties for anything that can actually be a compile-time decision. If it can't be, then so be it. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote: 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. As a side note - I think it would be cool if we used more specific names than "Backend" and "Frontened" in the actual code, since which end is front and back is not always obvious nor always agreed upon by all observers. I like Proxy and Impl ok as name pairs, not sure if that's the same relationship you have in mind. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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 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 wrote: > >> >> >> On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow wrote: >> >>> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow wrote: >>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig wrote: > On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow 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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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 wrote: > > > On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow wrote: > >> On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow wrote: >> >>> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig wrote: >>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow wrote: > On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow wrote: > >> On Tue, May 26, 2009 at 5:05 PM, Sam Weinig wrote: >> >>> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 5:00 PM, Sam Weinig wrote: > On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek 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 > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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 wrote: > On Tue, May 26, 2009 at 6:02 PM, Michael Nordman > 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" > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 6:02 PM, Michael Nordman 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" ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
> 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. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow wrote: > On Tue, May 26, 2009 at 5:05 PM, Sam Weinig wrote: > >> On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 5:05 PM, Sam Weinig wrote: > On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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.) SoI'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 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 ideasI'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 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 version. >> >> -atw >> >> >> On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak 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
Re: [webkit-dev] SharedWorkers alternate design
John's point about switching which impl to use at runtime is a good one. For example, I was planning on doing something similar for the ApplicationCacheFrontend interface, but with a difference. I was planning on returning one concrete instance when called on the main thread, and another when called on a worker thread... a runtime decision. I think the interface + static factory approach is generally easier to grok than the FooBase / Foo (elsewhere) approach... jmho. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On May 26, 2009, at 10:43 AM, Drew Wilson 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? This is apparently done via include paths in the various project files. 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 version. With the Base pattern, it's not necessary to give the port-specific subclasses special names. But if a name becomes necessary I'd say "generic" or "default" or something like that. Regards, Maciej -atw On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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 ideasI'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 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 version. > > -atw > > > On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak 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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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. Chromium doesn't have this use case for SharedWorkerRepository, so it doesn't need to be an interface if that's more consistent with WebKit code. Apology for the wrong suggestion Drew :) On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak 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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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 version. -atw On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak 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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
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. -atw On Mon, May 25, 2009 at 10:41 PM, John Abd-El-Malek wrote: > > > On Fri, May 22, 2009 at 2:50 PM, Jeremy Orlow wrote: > >> On Fri, May 22, 2009 at 2:25 PM, Drew Wilson wrote: >> >>> Following up on this, I had a question about the best way to enable the >>> implementation of SharedWorkerRepository to vary for different platforms. >>> I'd like to provide a default WebKit implementation, but on Chromium we'll >>> want to provide an implementation that proxies shared worker operations to >>> the browser process - it is unlikely that the two implementations will share >>> very much (any?) code. >>> >>> The current design just defines SharedWorkerRepository as an interface, >>> then has a platform-specific static factory which returns an instance of >>> this class - the idea is that I'd provide a default WebKit implementation >>> (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that >>> want their own implementation) can provide their own factory method and >>> implementation (for an example of this, see WorkerContextProxy::create() in >>> WebCore/worker/WorkerMessagingProxy.cpp. >>> >>> Is this an acceptable approach? Other approaches I've seen either scatter >>> ifdefs around in header files (see KURL.h for an example) which seems >>> non-ideal for our case which won't have any shared code, or to have separate >>> platform-specific subdirectories, but I'm not certain what the naming >>> convention is for a directory that contains ">> but chromium>". >>> >>> I think the interface + static factory approach is the cleanest, >> >> >> This is the gist of what I'm planning for LocalStorage and I believe what >> Michael's planning for AppCache. At least in my case, I think I'll be able >> to share a substantial amount of code by running the backend of the code in >> the chromium browser process. >> > > I also agree this is the cleanest approach. Especially for these kind of > objects (workers, storage) that aren't created or called that frequently, > the memory and performance overhead is negligible. One other benefit is > that it allows platforms to both define their own implementations and to use > the default WebKit implementation. > >> >> >> >>> but I've gotten the impression that the use of virtual functions to vary >>> implementations per-platform is frowned upon in WebKit. Any advice for me? >>> >>> -atw >>> >>> >>> >>> >>> On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen < >>> kenneth.christian...@openbossa.org> wrote: >>> I believe Qt uses instance() in this situation. > Sadly we have not yet found a good verb for the common "get or create" > idiom. Cheers. Kenneth >>> >>> >>> ___ >>> webkit-dev mailing list >>> webkit-dev@lists.webkit.org >>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >>> >>> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Fri, May 22, 2009 at 2:50 PM, Jeremy Orlow wrote: > On Fri, May 22, 2009 at 2:25 PM, Drew Wilson wrote: > >> Following up on this, I had a question about the best way to enable the >> implementation of SharedWorkerRepository to vary for different platforms. >> I'd like to provide a default WebKit implementation, but on Chromium we'll >> want to provide an implementation that proxies shared worker operations to >> the browser process - it is unlikely that the two implementations will share >> very much (any?) code. >> >> The current design just defines SharedWorkerRepository as an interface, >> then has a platform-specific static factory which returns an instance of >> this class - the idea is that I'd provide a default WebKit implementation >> (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that >> want their own implementation) can provide their own factory method and >> implementation (for an example of this, see WorkerContextProxy::create() in >> WebCore/worker/WorkerMessagingProxy.cpp. >> >> Is this an acceptable approach? Other approaches I've seen either scatter >> ifdefs around in header files (see KURL.h for an example) which seems >> non-ideal for our case which won't have any shared code, or to have separate >> platform-specific subdirectories, but I'm not certain what the naming >> convention is for a directory that contains "> but chromium>". >> >> I think the interface + static factory approach is the cleanest, > > > This is the gist of what I'm planning for LocalStorage and I believe what > Michael's planning for AppCache. At least in my case, I think I'll be able > to share a substantial amount of code by running the backend of the code in > the chromium browser process. > I also agree this is the cleanest approach. Especially for these kind of objects (workers, storage) that aren't created or called that frequently, the memory and performance overhead is negligible. One other benefit is that it allows platforms to both define their own implementations and to use the default WebKit implementation. > > > >> but I've gotten the impression that the use of virtual functions to vary >> implementations per-platform is frowned upon in WebKit. Any advice for me? >> >> -atw >> >> >> >> >> On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen < >> kenneth.christian...@openbossa.org> wrote: >> >>> I believe Qt uses instance() in this situation. >>> >>> > Sadly we have not yet found a good verb for the common "get or create" >>> > idiom. >>> >>> Cheers. >>> Kenneth >>> >> >> >> ___ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> >> > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Fri, May 22, 2009 at 2:25 PM, Drew Wilson wrote: > Following up on this, I had a question about the best way to enable the > implementation of SharedWorkerRepository to vary for different platforms. > I'd like to provide a default WebKit implementation, but on Chromium we'll > want to provide an implementation that proxies shared worker operations to > the browser process - it is unlikely that the two implementations will share > very much (any?) code. > > The current design just defines SharedWorkerRepository as an interface, > then has a platform-specific static factory which returns an instance of > this class - the idea is that I'd provide a default WebKit implementation > (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that > want their own implementation) can provide their own factory method and > implementation (for an example of this, see WorkerContextProxy::create() in > WebCore/worker/WorkerMessagingProxy.cpp. > > Is this an acceptable approach? Other approaches I've seen either scatter > ifdefs around in header files (see KURL.h for an example) which seems > non-ideal for our case which won't have any shared code, or to have separate > platform-specific subdirectories, but I'm not certain what the naming > convention is for a directory that contains " but chromium>". > > I think the interface + static factory approach is the cleanest, This is the gist of what I'm planning for LocalStorage and I believe what Michael's planning for AppCache. At least in my case, I think I'll be able to share a substantial amount of code by running the backend of the code in the chromium browser process. > but I've gotten the impression that the use of virtual functions to vary > implementations per-platform is frowned upon in WebKit. Any advice for me? > > -atw > > > > > On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen < > kenneth.christian...@openbossa.org> wrote: > >> I believe Qt uses instance() in this situation. >> >> > Sadly we have not yet found a good verb for the common "get or create" >> > idiom. >> >> Cheers. >> Kenneth >> > > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
On Fri, May 22, 2009 at 12:30 PM, Darin Adler wrote: > Sadly we have not yet found a good verb for the common "get or create" > idiom. My own code uses "createObjectIfNeeded()" and similar variants. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
Following up on this, I had a question about the best way to enable the implementation of SharedWorkerRepository to vary for different platforms. I'd like to provide a default WebKit implementation, but on Chromium we'll want to provide an implementation that proxies shared worker operations to the browser process - it is unlikely that the two implementations will share very much (any?) code. The current design just defines SharedWorkerRepository as an interface, then has a platform-specific static factory which returns an instance of this class - the idea is that I'd provide a default WebKit implementation (called SharedWorkerProxyImpl.cpp?), then Chromium (or other platforms that want their own implementation) can provide their own factory method and implementation (for an example of this, see WorkerContextProxy::create() in WebCore/worker/WorkerMessagingProxy.cpp. Is this an acceptable approach? Other approaches I've seen either scatter ifdefs around in header files (see KURL.h for an example) which seems non-ideal for our case which won't have any shared code, or to have separate platform-specific subdirectories, but I'm not certain what the naming convention is for a directory that contains "". I think the interface + static factory approach is the cleanest, but I've gotten the impression that the use of virtual functions to vary implementations per-platform is frowned upon in WebKit. Any advice for me? -atw On Fri, May 22, 2009 at 1:20 PM, Kenneth Christiansen < kenneth.christian...@openbossa.org> wrote: > I believe Qt uses instance() in this situation. > > > Sadly we have not yet found a good verb for the common "get or create" > > idiom. > > Cheers. > Kenneth > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
I believe Qt uses instance() in this situation. > Sadly we have not yet found a good verb for the common "get or create" > idiom. Cheers. Kenneth ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
Thanks - I hadn't realized that about WebKit style. I've updated the interfaces to use different verbs (like "createWorkerProxy()") or omit the verb entirely where appropriate. -atw On Fri, May 22, 2009 at 12:30 PM, Darin Adler wrote: > No substantive comment, but a small style comment. > > On May 21, 2009, at 4:20 PM, Drew Wilson wrote: > > // Static factory method for getting the correct repository >> implementation for a given browser >> static public SharedWorkerRepository* getRepository(); >> > > Generally WebKit does not use the verb "get" to name functions that simply > return something. Instead for those we simply use a noun. > > If there is some real action involved, then we would want to use a verb, > but not "get". For example, if the function always creates something we can > use the word create. > > Sadly we have not yet found a good verb for the common "get or create" > idiom. > >-- Darin > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SharedWorkers alternate design
No substantive comment, but a small style comment. On May 21, 2009, at 4:20 PM, Drew Wilson wrote: // Static factory method for getting the correct repository implementation for a given browser static public SharedWorkerRepository* getRepository(); Generally WebKit does not use the verb "get" to name functions that simply return something. Instead for those we simply use a noun. If there is some real action involved, then we would want to use a verb, but not "get". For example, if the function always creates something we can use the word create. Sadly we have not yet found a good verb for the common "get or create" idiom. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
