subject:"\[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



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

2009-06-02 Thread Drew Wilson

2009/6/1 Alexey Proskuryakov a...@webkit.org


 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

2009-06-02 Thread 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.

 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 a...@webkit.org:

 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



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



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

2009-06-02 Thread Michael Nordman

2009/6/2 Alexey Proskuryakov a...@webkit.org:

 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



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-06-02 Thread 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 a...@webkit.org


 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-06-02 Thread Michael Nordman

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 atwil...@google.com:

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 a...@webkit.org

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-06-01 Thread 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

2009-06-01 Thread Drew Wilson

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 a...@webkit.org


 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

2009-06-01 Thread 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.


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

2009-06-01 Thread Drew Wilson

2009/6/1 Alexey Proskuryakov a...@webkit.org


 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

2009-06-01 Thread 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 atwil...@google.com:


 2009/6/1 Alexey Proskuryakov a...@webkit.org

 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

Re: [webkit-dev] SharedWorkers alternate design

2009-06-01 Thread Drew Wilson

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 micha...@google.com

 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 atwil...@google.com:
 
 
  2009/6/1 Alexey Proskuryakov a...@webkit.org
 
  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

Re: [webkit-dev] SharedWorkers alternate design

2009-05-28 Thread Michael Nordman

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

2009-05-28 Thread Jeremy Orlow

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 micha...@google.comwrote:

 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

2009-05-28 Thread Michael Nordman

 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

2009-05-28 Thread Maciej Stachowiak



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

2009-05-27 Thread Jeremy Orlow

On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak m...@apple.com 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

2009-05-27 Thread Jeremy Orlow

On Tue, May 26, 2009 at 9:42 PM, Maciej Stachowiak m...@apple.com 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

2009-05-27 Thread Maciej Stachowiak



On May 27, 2009, at 12:00 AM, Jeremy Orlow wrote:

On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak m...@apple.com  
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

2009-05-27 Thread Michael Nordman

 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

2009-05-27 Thread John Abd-El-Malek

On Wed, May 27, 2009 at 12:00 AM, Jeremy Orlow jor...@chromium.org wrote:

 On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak m...@apple.com 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

2009-05-27 Thread Jeremy Orlow

On Wed, May 27, 2009 at 3:37 PM, John Abd-El-Malek j...@google.com wrote:



 On Wed, May 27, 2009 at 12:00 AM, Jeremy Orlow jor...@chromium.orgwrote:

 On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak m...@apple.com 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

2009-05-26 Thread Drew Wilson

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 j...@google.com wrote:



 On Fri, May 22, 2009 at 2:50 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Fri, May 22, 2009 at 2:25 PM, Drew Wilson atwil...@google.com 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 implementation for everything
 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

2009-05-26 Thread Darin Adler


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



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

2009-05-26 Thread Drew Wilson

Thanks for the explanation, Maciej. I actually looked at ResourceRequest
prior to sending my mail, but I wasn't clear what makefile magic was being
used to load the correct version of ResourceRequest.h for a given platform.

For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see only
two references to ResourceRequest.h: platform/network/curl and
platform/network/cf, but clearly we might want to use the chromium/ or win/
versions as well. Can someone give me a quick explanation of how the
platform-specific version is selected at compile time?

Do we have a naming convention for the default implementation? I'm
expecting there to be two versions of SharedWorkerRepository - the chromium
version, and the everything else version.

-atw

On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak m...@apple.com wrote:


 On May 26, 2009, at 10:21 AM, Darin Adler wrote:

  On May 26, 2009, at 10:16 AM, Drew Wilson wrote:

  OK, I've got two strong votes for the interface + static factory
 approach. Any objections from the rest of the WebKit team? If I don't hear
 any counter proposals, I'll do that.


 I think it's unpleasant to pay run-time cost for a compile-time choice.
 Sure, sometimes the extra cost is no big deal, but sometimes it can be a big
 deal and I see no reason to choose idioms that use virtual functions if
 there are equally good or better ones that don't.

 Are there really no better techniques than abstract base classes and
 virtual functions for this sort of compile-time switch? How about the
 technique used for ResourceRequest and ResourceResponse? Maybe Darin Fisher
 can explain that one.


 I agree with Darin's comments here. We've tried hard to avoid using runtime
 polymorphism for compile-time choices. Here it's probably not
 performance-critical, but it can be avoided.

 The ResourceRequestBase / ResourceRequest model (due to Darin Fisher) seems
 pretty clean to me. I would like to see more of our classes with
 port-specific implementation details move to this style. I think it could
 work for SharedWorkerRepository.

 The basic idea is this. Let's say you have a class FooBar.

 - You define a FooBarBase class that has the cross-platform interface and
 data members. But not all the methods are actually implemented in the
 cross-platform code. All of its constructors are protected so the class
 cannot be instantiated directly.
 - Each port subclasses FooBarBase to define FooBar, adding constructors,
 platform-specific data members, and any needed platform-specific private
 helpers or type conversions.
 - Each port implements the methods of FooBarBase that are
 platform-specific, freely downcasting to FooBar when needed since we have
 guaranteed that every instance of FooBarBase is actually a FooBar.
 - Cross-platform code using the class just uses FooBar. The Base class is
 an implementation detail.

 (Darin F., please correct me if I have not done justice to this technique.)

 Note that this method has no runtime cost - there's no need to use virtual
 methods or other forms of runtime indirection. And there's no need to #ifdef
 any headers, everything is controlled purely by including the right platform
 specific FooBar.h so it can be handled by include paths. It's a little
 subtle at first but I think it results in nice, understandable code.

 I think we should document this technique as the preferred way to make
 classes with port-specific implementation details and convert more of
 WebCore/platform/ to this technique, as well as using it for new classes.

 Regards,
 Maciej


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

2009-05-26 Thread John Abd-El-Malek

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 m...@apple.com wrote:


 On May 26, 2009, at 10:21 AM, Darin Adler wrote:

  On May 26, 2009, at 10:16 AM, Drew Wilson wrote:

  OK, I've got two strong votes for the interface + static factory
 approach. Any objections from the rest of the WebKit team? If I don't hear
 any counter proposals, I'll do that.


 I think it's unpleasant to pay run-time cost for a compile-time choice.
 Sure, sometimes the extra cost is no big deal, but sometimes it can be a big
 deal and I see no reason to choose idioms that use virtual functions if
 there are equally good or better ones that don't.

 Are there really no better techniques than abstract base classes and
 virtual functions for this sort of compile-time switch? How about the
 technique used for ResourceRequest and ResourceResponse? Maybe Darin Fisher
 can explain that one.


 I agree with Darin's comments here. We've tried hard to avoid using runtime
 polymorphism for compile-time choices. Here it's probably not
 performance-critical, but it can be avoided.

 The ResourceRequestBase / ResourceRequest model (due to Darin Fisher) seems
 pretty clean to me. I would like to see more of our classes with
 port-specific implementation details move to this style. I think it could
 work for SharedWorkerRepository.

 The basic idea is this. Let's say you have a class FooBar.

 - You define a FooBarBase class that has the cross-platform interface and
 data members. But not all the methods are actually implemented in the
 cross-platform code. All of its constructors are protected so the class
 cannot be instantiated directly.
 - Each port subclasses FooBarBase to define FooBar, adding constructors,
 platform-specific data members, and any needed platform-specific private
 helpers or type conversions.
 - Each port implements the methods of FooBarBase that are
 platform-specific, freely downcasting to FooBar when needed since we have
 guaranteed that every instance of FooBarBase is actually a FooBar.
 - Cross-platform code using the class just uses FooBar. The Base class is
 an implementation detail.

 (Darin F., please correct me if I have not done justice to this technique.)

 Note that this method has no runtime cost - there's no need to use virtual
 methods or other forms of runtime indirection. And there's no need to #ifdef
 any headers, everything is controlled purely by including the right platform
 specific FooBar.h so it can be handled by include paths. It's a little
 subtle at first but I think it results in nice, understandable code.

 I think we should document this technique as the preferred way to make
 classes with port-specific implementation details and convert more of
 WebCore/platform/ to this technique, as well as using it for new classes.

 Regards,
 Maciej


 ___
 webkit-dev mailing list
 webkit-dev@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

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 atwil...@google.com wrote:

 Thanks for the explanation, Maciej. I actually looked at ResourceRequest
 prior to sending my mail, but I wasn't clear what makefile magic was being
 used to load the correct version of ResourceRequest.h for a given platform.

 For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see only
 two references to ResourceRequest.h: platform/network/curl and
 platform/network/cf, but clearly we might want to use the chromium/ or win/
 versions as well. Can someone give me a quick explanation of how the
 platform-specific version is selected at compile time?

 Do we have a naming convention for the default implementation? I'm
 expecting there to be two versions of SharedWorkerRepository - the chromium
 version, and the everything else version.

 -atw


 On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak m...@apple.com wrote:


 On May 26, 2009, at 10:21 AM, Darin Adler wrote:

  On May 26, 2009, at 10:16 AM, Drew Wilson wrote:

  OK, I've got two strong votes for the interface + static factory
 approach. Any objections from the rest of the WebKit team? If I don't hear
 any counter proposals, I'll do that.


 I think it's unpleasant to pay run-time cost for a compile-time choice.
 Sure, sometimes the extra cost is no big deal, but sometimes it can be a big
 deal and I see no reason to choose idioms that use virtual functions if
 there are equally good or better ones that don't.

 Are there really no better techniques than abstract base classes and
 virtual functions for this sort of compile-time switch? How about the
 technique used for ResourceRequest and ResourceResponse? Maybe Darin Fisher
 can explain that one.


 I agree with Darin's comments here. We've tried hard to avoid using
 runtime polymorphism for compile-time choices. Here it's probably not
 performance-critical, but it can be avoided.

 The ResourceRequestBase / ResourceRequest model (due to Darin Fisher)
 seems pretty clean to me. I would like to see more of our classes with
 port-specific implementation details move to this style. I think it could
 work for SharedWorkerRepository.

 The basic idea is this. Let's say you have a class FooBar.

 - You define a FooBarBase class that has the cross-platform interface and
 data members. But not all the methods are actually implemented in the
 cross-platform code. All of its constructors are protected so the class
 cannot be instantiated directly.
 - Each port subclasses FooBarBase to define FooBar, adding constructors,
 platform-specific data members, and any needed platform-specific private
 helpers or type conversions.
 - Each port implements the methods of FooBarBase that are
 platform-specific, freely downcasting to FooBar when needed since we have
 guaranteed that every instance of FooBarBase is actually a FooBar.
 - Cross-platform code using the class just uses FooBar. The Base class is
 an implementation detail.

 (Darin F., please correct me if I have not done justice to this
 technique.)

 Note that this method has no runtime cost - there's no need to use virtual
 methods or other forms of runtime indirection. And there's no need to #ifdef
 any headers, everything is controlled purely by including the right platform
 specific FooBar.h so it can be handled by include paths. It's a little
 subtle at first but I think it results in nice, understandable code.

 I think we should document this technique as the preferred way to make
 classes with port-specific implementation details and convert more of
 WebCore/platform/ to this technique, as well as using it for new classes.

 Regards,
 Maciej



 ___
 webkit-dev mailing list
 webkit-dev@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

2009-05-26 Thread Michael Nordman

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

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 jor...@chromium.org wrote:

 Note that Chromium uses the same binary/libraries for the render process
 and the browser process, which means that the decision can't be made in
 compile time for us.

 There might be ways (like what you mentioned) to allow the compiler to skip
 all the virtual stuff for implementations where the decision can be made in
 compile time (the normal case).  I've got some 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 atwil...@google.com wrote:

 Thanks for the explanation, Maciej. I actually looked at ResourceRequest
 prior to sending my mail, but I wasn't clear what makefile magic was being
 used to load the correct version of ResourceRequest.h for a given platform.

 For example, if I look at WebCore/WebCore.vcproj/WebCore.vcproj, I see
 only two references to ResourceRequest.h: platform/network/curl and
 platform/network/cf, but clearly we might want to use the chromium/ or win/
 versions as well. Can someone give me a quick explanation of how the
 platform-specific version is selected at compile time?

 Do we have a naming convention for the default implementation? I'm
 expecting there to be two versions of SharedWorkerRepository - the chromium
 version, and the everything else version.

 -atw


 On Tue, May 26, 2009 at 10:36 AM, Maciej Stachowiak m...@apple.comwrote:


 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

Re: [webkit-dev] SharedWorkers alternate design

2009-05-26 Thread Sam Weinig

On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek j...@google.com wrote:

 I agree that this approach is powerful.  However there are (not too
 frequent) situations when a port like Chromium wants to use both the WebKit
 implementation and its own implementation, switching in runtime.  For
 workers, this happened with WorkerContextProxy/WorkerObjectProxy which are
 the interfaces that a worker object implements/uses.  Since workers run in a
 separate process from the renderer, we use our own implementations of these
 interfaces that know about IPC etc.  However once we're in the worker
 process, we want to run nested workers in the same process, in which case we
 want to use the WebKit implementation of these interfaces directly without
 using Chromium's.


This doesn't seem like a runtime choice, but rather a use-time choice.  In
the main context, you want use one implementation and in the worker context,
another one.  This to me implies two different objects with different names.
 In non-multiprocess implementations of WebKit, these two objects could be
the same object, and in multiprocess implementations (such as Chromium),
they could be backed by different objects.  This would not incur a runtime
cost (and would be, subjectively of course, clearer).

-Sam
___
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 sam.wei...@gmail.com wrote:

 On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow jor...@chromium.org wrote:

 The common case is definitely that we know whether we want the proxy (for
 IPC) or the implementation at compile time.  In some cases (like Chromium)
 this is not known until initialization time.


  What do you mean by initialization time?  Is it the case that you know
 which one you want at each call site?  Or do literally want to make a
 runtime choice based on state?


Well, I meant that we always want one or the other based on if the process
is being used as a render process (i.e. sandboxed, running WebKit but with
all DOM Storage calls proxied) or a browser process (i.e. running only
selected parts of WebCore like the DOM Storage backend/implementation).


Come to think of it (IIRC) all calls to the StorageBackend within the
WebCore code should go through a proxy for Chromium.  The proxy will then
call into Chromium's webkit bridge/glue, which will pass the message through
the IPC layer, which will call back into bridge/glue code, which will be
interacting with the real implementation.

If that's true, then the implementation could be very explicitly split into
2 (with frontend code calling backend proxy code and vice versa) and single
process implementations could simply typedef _Proxy to _Impl (or
Implementation, or Base, or whatever you want to call it).

or have I completely confused myself?

J
___
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 jor...@chromium.org wrote:

 On Tue, May 26, 2009 at 5:05 PM, Sam Weinig sam.wei...@gmail.com wrote:

 On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow jor...@chromium.orgwrote:

 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

2009-05-26 Thread Michael Nordman

 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 6:02 PM, Michael Nordman micha...@google.comwrote:

  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

2009-05-26 Thread John Abd-El-Malek

On Tue, May 26, 2009 at 5:00 PM, Sam Weinig sam.wei...@gmail.com wrote:

 On Tue, May 26, 2009 at 11:08 AM, John Abd-El-Malek j...@google.comwrote:

 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

2009-05-26 Thread John Abd-El-Malek

On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Tue, May 26, 2009 at 5:05 PM, Sam Weinig sam.wei...@gmail.com wrote:

 On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow jor...@chromium.orgwrote:

 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

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 j...@google.com wrote:



 On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow jor...@chromium.org wrote:

 On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow jor...@chromium.orgwrote:

 On Tue, May 26, 2009 at 5:05 PM, Sam Weinig sam.wei...@gmail.comwrote:

 On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow jor...@chromium.orgwrote:

 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

2009-05-26 Thread David Levin

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 jor...@chromium.org wrote:

 It might also be worth bringing back up the unanswered quesiton of whether
 this is even worth it for AppCache and LocalStorage.  As I mentioned, my
 (less than scientific) testing indicated no.*  Maybe we're prematurely
 optimizing here?  I definitely agree that virtual functions should be
 avoided in code that's often called, but even AppCache doesn't really seem
 to fit into that category.

 Jeremy

 * I have a test page that calls window.localStorage 100,000 times,
 localStorage.setItem(foo, bar) 100,000 times, and localStorage.getItem(foo)
 1,000,000 times.  All of these take under half a second, and the times don't
 really change with my new implementation which does use virtual dispatch.



 On Tue, May 26, 2009 at 7:00 PM, John Abd-El-Malek j...@google.com wrote:



 On Tue, May 26, 2009 at 5:31 PM, Jeremy Orlow jor...@chromium.orgwrote:

 On Tue, May 26, 2009 at 5:21 PM, Jeremy Orlow jor...@chromium.orgwrote:

 On Tue, May 26, 2009 at 5:05 PM, Sam Weinig sam.wei...@gmail.comwrote:

 On Tue, May 26, 2009 at 4:12 PM, Jeremy Orlow jor...@chromium.orgwrote:

 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



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



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