Re: [webkit-dev] Multiprocess networking in WebKit

[Michael Nordman]

About MemCache considerations, you list these options...
* Do not share storage
* Share storage but hits in remote caches are asynchronous
* Share storage and all cache hits are serviced synchronously

Is there a fourth option?
* Share storage and all cache hits are async in all cases (the resulting
handle is returned asyncly, but the data is then directly addressable).

And then maybe a fifth two-tiered option that builds on the above to get to
something more satisfying?
* Shared storage is accessible asyncly at the level of ResourceHandle (that
fourth option).
* Local handles to shared resources are accessible syncly at the level of
todays MemCache, where the local memcache gets populated with handles to
resources in shared storage.

I'm merrily ignoring how decoded data is also associated with
CacheResources (and how it can mutate depending on attributes of the
Document for which it was most recently decoded).





On Mon, Dec 3, 2012 at 4:16 PM, Adam Barth  wrote:

> There's been a somewhat fragmented discussion across webkit-dev and
> various bugs about how we ought to approach multiprocess networking in
> WebKit.  In an attempt to organize my thoughts, I wrote up a short
> design document that compares various approaches:
>
>
> https://docs.google.com/document/d/1ihpwbiG_EDirnLibkkglEtyFoEEcf7t9XNAn8JD4fQY/edit
>
> My hope is that this document will be useful as a starting point for
> discussion.  If other folks have written similar documents, those
> might make valuable contributions to the discussion as well.
>
> I welcome your feedback, either via comments in the document or via
> this email thread.
>
> Thanks,
> Adam
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Notifications for Blob serialization/deserialization

[Michael Nordman]

On Tue, Jul 3, 2012 at 4:08 PM, Greg Billock  wrote:

> Do you think the way my patch does this, by exposing two new methods on
> the BlobController for notifying serialization and deserialization, will be
> sufficient?



For IndexedDB, it looks to me that notifications like this (or on the
> BlobData ID, as you propose) will be critical -- the IndexedDB will need to
> read the blob values to store them, at which time it can release the refs
> it holds. The math won't work out unless it can know that the ref it just
> deleted was given to it in serialization, which my notifier would
> accomplish. Similarly for history -- if history supports Blob, then
> packaging that serialization needs to hold the refcount.
>
> All these use cases amount to the same thing: use of a serialized Blob
> outside the "normal" usage of creation/deletion within a single context. I
> think we're all in agreement that Blob semantics according to the spec
> should support this use case, even if Blob URLs explicitly don't.
>
> Do you want to revamp the management API to use BlobData IDs before adding
> a pair of de/serialization APIs? If we do, we can skip some of the
> nastiness here, like managing an extra serialization internal URL. It'll
> definitely be easier to see. If that's going to take a while, though, I'd
> like to get a preliminary solution in place so web intents can use blobs.
>

I'd vote to decouple proximate fixes from general revampage if possible so
we don't hold worthy capabilities hostage to housecleaning. Being able
to utilize blobs in webintent payloads seems pretty valuable.


>
> Who's a good person to ask about the history API's support (or lack
> thereof) of Blobs?
>

Thnx for pointing out the the pushstate / history use-case, i didn't know
about that one. I'm not sure who all knows about that?


>
>
> On Tue, Jun 26, 2012 at 2:54 PM, Michael Nordman wrote:
>
>> I think revamping our Blob handling is one of the projects that I should
>> be working on next. What we have now is proving to be too difficult to work
>> with in a variety of ways.
>>
>> The more i look at this particular difficulty with sending blobs within
>> serialized values (within chromium), the more convinced i am that we should
>> switch to identifying the 'data underlying a blob' rather than the 'blob
>> object instance'. Currently our 'ids' identify a WebCore::Blob instance.
>> The trouble with putting ids on blob object instances is that they dont
>> cross process boundaries, so we end up either trying to create the id in
>> advance of the instance in some other process, or relying on the
>> originating instance still being around when the new instance in the other
>> process gets coined (based on the originals ids). We have to juggle 2 ids
>> instead of one and conceptually its just a mess.
>>
>> What I'm thinking about is changes along these lines...
>>
>> * WebCore::Blobs have an 'id' that refers to the 'data'. At ctor and dtor
>> time, they increment/decrement a refcount, via ipcs, on the underlying
>> 'data' in the main browser. A clone or copy of that WebCore::Blob instance
>> anywhere in the system will carry that same 'id' and do that same
>> refcounting of the underlying data.
>>
>> * When a IPC message containing a serialized blob (the id value) is in
>> transit, extra refs are applied to the underlying blob data. There are
>> several cases where we need to consider a blob as 'in transit'. Being
>> referred to in an WebCore::SSV is one place. Being referred to in a
>> content::SSV is another. As those objects come and go, they should inc/dec
>> any blobs they refer to accordingly. A content::SSV has to distinguish
>> between running in the main browser process and a child process to do that
>> properly.
>>
>> * A challenging case is when sending SSVs containing blobs from the
>> browser process to a child (renderer|worker) process. After a message is
>> put on the wire going that direction, its not safe to deref the blob data
>> until the receiving side has picked it up and added a ref of its own. I
>> think we'll need ACKS for messages flowing in that direction so the
>> browser-side knows when its safe to drop the extra in transit ref.
>>
>> * Its easier going the other way, from child to browser, since if the
>> child has a ref when the 'id' is put on the wire, that ref cant possibly be
>> removed prior to that msg reaching the browser.
>>
>> Not sure how much of this disccusion affects webkit's native blob

Re: [webkit-dev] Notifications for Blob serialization/deserialization

[Michael Nordman]

I think revamping our Blob handling is one of the projects that I should be
working on next. What we have now is proving to be too difficult to work
with in a variety of ways.

The more i look at this particular difficulty with sending blobs within
serialized values (within chromium), the more convinced i am that we should
switch to identifying the 'data underlying a blob' rather than the 'blob
object instance'. Currently our 'ids' identify a WebCore::Blob instance.
The trouble with putting ids on blob object instances is that they dont
cross process boundaries, so we end up either trying to create the id in
advance of the instance in some other process, or relying on the
originating instance still being around when the new instance in the other
process gets coined (based on the originals ids). We have to juggle 2 ids
instead of one and conceptually its just a mess.

What I'm thinking about is changes along these lines...

* WebCore::Blobs have an 'id' that refers to the 'data'. At ctor and dtor
time, they increment/decrement a refcount, via ipcs, on the underlying
'data' in the main browser. A clone or copy of that WebCore::Blob instance
anywhere in the system will carry that same 'id' and do that same
refcounting of the underlying data.

* When a IPC message containing a serialized blob (the id value) is in
transit, extra refs are applied to the underlying blob data. There are
several cases where we need to consider a blob as 'in transit'. Being
referred to in an WebCore::SSV is one place. Being referred to in a
content::SSV is another. As those objects come and go, they should inc/dec
any blobs they refer to accordingly. A content::SSV has to distinguish
between running in the main browser process and a child process to do that
properly.

* A challenging case is when sending SSVs containing blobs from the browser
process to a child (renderer|worker) process. After a message is put on the
wire going that direction, its not safe to deref the blob data until the
receiving side has picked it up and added a ref of its own. I think we'll
need ACKS for messages flowing in that direction so the browser-side knows
when its safe to drop the extra in transit ref.

* Its easier going the other way, from child to browser, since if the child
has a ref when the 'id' is put on the wire, that ref cant possibly be
removed prior to that msg reaching the browser.

Not sure how much of this disccusion affects webkit's native blob handling
really? This whole chromium multi-process problem doesn't exist there. I
think we can put high level abstractions in webcore that we then fork at
that high level... and the forked chromium impl deals with the complexities
in our multi-process case w/o impatcing webcore's native single process
impl.

Another source of difficulty stems from how the ThreadableBlobRegistry
posts all operations to the 'main' webkit thread. That's not going to work
very well with how we handle IDB operations entirely from the 'context'
thread even if its a background worker context. Message sent on behalf of
blobs take a longer slower route to reach our main browser process than
those sent on behalf of IDB, so an IDB message that contains a blob id may
reach the main browser prior to the blob messages that create that blob
reach the main browser. I think we have to avoid going thru the 'main'
webkit thread in the chromium port for the blob handling messages to avoid
odd races.



On Tue, Jun 26, 2012 at 11:03 AM, Joshua Bell  wrote:

> On Tue, Jun 26, 2012 at 10:19 AM, Greg Billock wrote:
>
>> I've been working with Michael Nordman on a problem related to Blob
>> serialization. Currently, if we serialize a Blob, there's no
>> notification to the BlobRegistry, so the serialized Blob will be
>> garbage collected at an indeterminate time if the context in which it
>> was created is closed. This lifetime scoping is spelled out clearly
>> for Blob URLs created using the URL API. I see nothing in the spec
>> imposing the same lifetime scoping on Blobs themselves, so I think it
>> is an implementation flaw. To correctly handle this serialization
>> case, however, the BlobRegistry needs to know when serialization and
>> deserialization operations happen for Blob objects.
>>
>> I've created a patch that adds that logic and plumbs it through to the
>> Chromium API. Webkit patch:
>> https://bugs.webkit.org/show_bug.cgi?id=89921 The corresponding
>> Chromium-side patch is here: http://codereview.chromium.org/10662024/
>>
>>
>> The strategy I used is to create a new internal URL and use that for
>> serialization:
>>
>>  KURL cloneURL = BlobURL::createInternalURL();
>>  blobRegistry().didSerializeBlob(cloneURL, blob->url()

Re: [webkit-dev] run-webkit-tests is moving to parallell testing by default (this weekend)

[Michael Nordman]

Some http tests make use of stateful php scritps with different tests
utlizing the same scripts in some cases. Does each 'worker' get a dedicated
http server instance or do they share the same http server?

On Mon, Dec 5, 2011 at 1:01 PM, Dirk Pranke  wrote:

> We never implemented the "general way of marking subdirectories as
> needing to run serially", but it would be easy to do if we needed to
> [the 'http' dirs are still special-cased in the code].
>
> There is code now (landed a few months ago) to control how many http
> tests run in parallel separately from the main parallelism flag (so
> you can run 16 workers but only 2 http tests at a time). I implemented
> it but never flipped the switch because it was in the middle of Eric
> flipping the bots over to NRWT in the first place. We should try
> experimenting with this to see at some point once everything
> stabilizes otherwise (this is the max_locked_shards() call in
> manager.py; there's no command line flag).
>
> -- Dirk
>
> On Mon, Dec 5, 2011 at 11:17 AM, Ojan Vafai  wrote:
> > Why is that? I don't know about other ports, but AFAIK, chromium writes
> to a
> > mock clipboard and the Apple mac port writes to a local OS clipboard
> > instance instead of the global one, specifically to avoid copy/paste
> tests
> > interacting. Even without running tests in parallel, it's probably a good
> > idea in order to avoid copy-pastes the developer is doing from affecting
> the
> > test run.
> >
> > That said, I believe we have a general way of marking subdirectories as
> > needing to run serially (which is what we do for http) if there are other
> > reasons we need to.
> >
> > On Mon, Dec 5, 2011 at 11:12 AM, David Levin  wrote:
> >>
> >> I believe there are some tests (copy/paste) that it would be very hard
> to
> >> fully shard due to how they work.
> >>
> >> dave
> >>
> >>
> >>
> >> On Mon, Dec 5, 2011 at 11:08 AM, Ojan Vafai  wrote:
> >>>
> >>> I looked at one example that didn't exit
> >>> early:
> http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28Tests%29/builds/35153/steps/layout-test/logs/stdio
> >>>
> >>> In that case, the http tests were the long tail and took 6 minutes
> longer
> >>> than all the other tests. We don't split the http tests up because
> every
> >>> time we've tried it's caused too much flakiness. It's unclear if the
> >>> flakiness points to a bug in the test harness (e.g. in how we setup
> apache)
> >>> or to bugs in the tests themselves or both. If someone has time to
> look into
> >>> this, this is probably the biggest benefit to be found in NRWT runtime
> when
> >>> running tests in parallel.
> >>>
> >>> FYI, NRWT outputs a log of the runtime after each run:
> >>>
> >>> 2011-12-03 03:09:30,018 58036 printing.py:462 INFO   worker/9:
>  4696
> >>> tests, 1746.63 secs
> >>> 2011-12-03 03:09:30,018 58036 printing.py:462 INFO   worker/8:
>  1177
> >>> tests, 1693.47 secs
> >>> 2011-12-03 03:09:30,018 58036 printing.py:462 INFO   worker/3:
>  1408
> >>> tests, 2033.51 secs
> >>> 2011-12-03 03:09:30,018 58036 printing.py:462 INFO   worker/2:
> 941
> >>> tests, 2119.65 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO   worker/1:
>  1121
> >>> tests, 2041.97 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO   worker/0:
>  1453
> >>> tests, 2515.75 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO   worker/7:
>  1189
> >>> tests, 1731.12 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO   worker/6:
>  3556
> >>> tests, 2114.37 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO   worker/5:
> 948
> >>> tests, 2097.13 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO   worker/4:
>  1411
> >>> tests, 1716.66 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO  worker/15:
> 795
> >>> tests, 2027.16 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO  worker/14:
>  1123
> >>> tests, 1732.72 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO  worker/13:
> 425
> >>> tests, 2021.25 secs
> >>> 2011-12-03 03:09:30,019 58036 printing.py:462 INFO  worker/12:
>  1175
> >>> tests, 1710.09 secs
> >>> 2011-12-03 03:09:30,020 58036 printing.py:462 INFO  worker/11:
>  3462
> >>> tests, 2096.30 secs
> >>> 2011-12-03 03:09:30,020 58036 printing.py:462 INFO  worker/10:
>  1449
> >>> tests, 1722.68 secs
> >>> 2011-12-03 03:09:30,020 58036 printing.py:462 INFO31120.45
> >>> cumulative, 1945.03 optimal
> >>>
> >>> That shows you that, if we fully sharded all the tests, they would in
> >>> theory take 1945 seconds to run, but worker/0 (the worker that runs
> the http
> >>> tests) took 2515 seconds to run.
> >>>
> >>> Ojan
> >>>
> >>> On Mon, Dec 5, 2011 at 6:55 AM, Adam Roben  wrote:
> 
>  On Dec 2, 2011, at 6:55 PM, Eric Seidel wrote:
> 
>  > The SnowLeopard bot went from a 1 hr 4 min (!?!) cycle time, to 38
> min
>  > (still !?!).
> 
>  I suspect ou

Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.

[Michael Nordman]

I sure hope specific exception messages are not getting codified in specs.

I don't see where the discussion of other browsers is relevant becaus it's
pretty clear other impls of this component aren't going to happen, yet this
remains a useful feature of webkit/chrome for the time being. It has issues
and i'd like to make it more useful.

>From a practical point of view, without being able to observe what error
conditions are actually arising makes improvements is more difficult. My
thought was to expose information about that to developers which would also
make its way back to us. There are a number of APIs that accept
'errorCallbacks', the messages delivered to those callbacks already contain
more detailed messages. At this point I'm looking at improving the
reporting for methods that directly throw exceptions. Most notable is the
openDatabase() method. A more detailed message is being logged to the
console, but i'd like that to be more directed into the hands of the
callers of that method.

Afaict, the "platform" does define a means of expressing exceptional
conditions including a means of conveying a message that ideally provides
useful information. I'd like to fill in that useful information part,
"INVALID_STATE_ERR: DOM Exception 11" isn't particularly useful to anyone.
Its fair to say INVALID_STATE for many distinct low level error conditions,
there's nothing wrong with the API. My intent in starting this thread was
to determine the best way of providing a more detailed message.  I don't
agree that "error messages are evil"? In the case of websql or indexedDB,
where there is a complex backing store of some kind that's likely different
across browsers, i think it is helpful to surface useful implementation
specific details for diagnostic and debugging purposes.






On Mon, Nov 14, 2011 at 5:56 PM, Adam Barth  wrote:

> On Mon, Nov 14, 2011 at 5:41 PM, Michael Nordman 
> wrote:
> > On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth  wrote:
> >>
> >> For SQLException, there are a hundred exception codes reserved,
> >>
> >> static const int SQLExceptionOffset = 1000;
> >> static const int SQLExceptionMax = 1099;
> >>
> >> of which, we appear to only be using eight.  It sounds like you're
> >> considering exposing more than a finite enumerated number of error
> >> codes, however.  Do we really want to make SQLite error messages part
> >> of the web platform?  What if we want to upgrade to a newer version of
> >> SQLite in the future (which might have different error codes)?
> >>
> >> IMHO, we shouldn't be investing much more effort into WebSQLDatabase.
> >> It's something of a dead-end for the platform.  If you're set on
> >> investing more effort, one path forward is to figure out which are the
> >> most important kinds of errors to distinguish and to give them error
> >> codes.  You can then give them descriptions as usual without needing
> >> any custom bindings.
> >
> > I don't want to change the set of exception 'codes' really.
> > There are significant clients of WebSQL. They can't transition to IDB
> until
> > it's up to the task and they've made that transition. For the time being,
> > I'm willing to better support websql. There are a errors in the wild and
> > figuring out what errors are "important" isn't as easy as it sounds.
> > See http://code.google.com/p/chromium/issues/detail?id=98939 about
> > "INVALID_STATE_ERR: DOM Exception 11".
> >
> > I'd like to be able to determine two things given the exception...
> callsite
> > in webcore that failed and the sqlite error code seen at that callsite.
> That
> > would make for a large number of new codes.
>
> The cost of exposing detailed error information is that all browsers
> that implement WebSQLDatabase will need to generate the exact same
> errors in the exact same situations.  Part of the reason why other
> browser vendors shot down WebSQLDatabase was that it was too reliant
> on implementation details of SQLite.  Exposing these ad-hoc error
> states as part of the platform just makes that problem worse,
> especially if you're talking about a large number of error conditions,
> as you seem to be.
>
> > If there's no general case for
> > returning a custom message, a reasonable option for me may be to use
> > [custom] bindings for these methods and to have that custom binding set
> the
> > exception message attribute accordingly.
>
> The issue isn't the best way of implementing this feature, the issue
> is whether we should be ex

Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.

[Michael Nordman]

On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth  wrote:

> For SQLException, there are a hundred exception codes reserved,
>
> static const int SQLExceptionOffset = 1000;
> static const int SQLExceptionMax = 1099;
>
> of which, we appear to only be using eight.  It sounds like you're
> considering exposing more than a finite enumerated number of error
> codes, however.  Do we really want to make SQLite error messages part
> of the web platform?  What if we want to upgrade to a newer version of
> SQLite in the future (which might have different error codes)?


> IMHO, we shouldn't be investing much more effort into WebSQLDatabase.
> It's something of a dead-end for the platform.  If you're set on
> investing more effort, one path forward is to figure out which are the
> most important kinds of errors to distinguish and to give them error
> codes.  You can then give them descriptions as usual without needing
> any custom bindings.
>

I don't want to change the set of exception 'codes' really.

There are significant clients of WebSQL. They can't transition to IDB until
it's up to the task and they've made that transition. For the time being,
I'm willing to better support websql. There are a errors in the wild and
figuring out what errors are "important" isn't as easy as it sounds. See
http://code.google.com/p/chromium/issues/detail?id=98939 about
"INVALID_STATE_ERR: DOM Exception 11".

I'd like to be able to determine two things given the exception... callsite
in webcore that failed and the sqlite error code seen at that callsite.
That would make for a large number of new codes. If there's no general case
for returning a custom message, a reasonable option for me may be to use
[custom] bindings for these methods and to have that custom binding set the
exception message attribute accordingly.


> Adam
>
>
> On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman 
> wrote:
> > I guess the exception of interest is  SQLException.
> > Take a look at Database.cpp line 103. The ' errorMessage' string on that
> > line contains more detailed information about what went wrong in the act
> of
> > opening the database, including things like an sqlite error code and
> sqlite
> > error message. These strings are formed in the bowls of
> > AbstractDatabase::performOpenAndVerify().
> >
> > On Mon, Nov 14, 2011 at 4:48 PM, Adam Barth  wrote:
> >>
> >> I'm not sure exactly what you're trying to do, but one option is to
> >> add a new type of DOMException:
> >>
> >>
> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in
> >>
> >> Another option is to customize the message from an existing exception
> >> (here are the DOMCore exceptions):
> >>
> >>
> >>
> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp
> >>
> >> If you show me the spec you're trying to implement, I might have a
> >> more concept suggestion of the best way to implement it.
> >>
> >> Adam
> >>
> >>
> >> On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman 
> >> wrote:
> >> > I have a case where given an IDL defined method thats defined to
> raise a
> >> > DOMException, I'd like to set a custom exception message from within
> the
> >> > webcore implementation and have that message percolate up into script
> >> > via
> >> > the bindings layer(s) and be accessible as the exception.message
> >> > attribute.
> >> > I don't see a non-custom way of doing that and am wondering if there
> >> > should
> >> > be support for something like this w/o having to resort to custom
> >> > bindings?
> >> > The particular methods I'm looking at are the openDatabase(...) method
> >> > of
> >> > DOMWindow and WorkerContext, but this seems like it might be useful in
> >> > other
> >> > cases as well.
> >> >
> >> > ___
> >> > 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] Custom exception messages for IDL defined methods that raise DOMException.

[Michael Nordman]

I guess the exception of interest is  SQLException.

Take a look at Database.cpp line 103. The ' errorMessage' string on that
line contains more detailed information about what went wrong in the act of
opening the database, including things like an sqlite error code and sqlite
error message. These strings are formed in the bowls of
AbstractDatabase::performOpenAndVerify().

On Mon, Nov 14, 2011 at 4:48 PM, Adam Barth  wrote:

> I'm not sure exactly what you're trying to do, but one option is to
> add a new type of DOMException:
>
> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in
>
> Another option is to customize the message from an existing exception
> (here are the DOMCore exceptions):
>
>
> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp
>
> If you show me the spec you're trying to implement, I might have a
> more concept suggestion of the best way to implement it.
>
> Adam
>
>
> On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman 
> wrote:
> > I have a case where given an IDL defined method thats defined to raise a
> > DOMException, I'd like to set a custom exception message from within the
> > webcore implementation and have that message percolate up into script via
> > the bindings layer(s) and be accessible as the exception.message
> attribute.
> > I don't see a non-custom way of doing that and am wondering if there
> should
> > be support for something like this w/o having to resort to custom
> bindings?
> > The particular methods I'm looking at are the openDatabase(...) method of
> > DOMWindow and WorkerContext, but this seems like it might be useful in
> other
> > cases as well.
> >
> > ___
> > 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] Custom exception messages for IDL defined methods that raise DOMException.

[Michael Nordman]

I have a case where given an IDL defined method thats defined to raise a
DOMException, I'd like to set a custom exception message from within the
webcore implementation and have that message percolate up into script via
the bindings layer(s) and be accessible as the exception.message attribute.
I don't see a non-custom way of doing that and am wondering if there should
be support for something like this w/o having to resort to custom bindings?

The particular methods I'm looking at are the openDatabase(...) method of
DOMWindow and WorkerContext, but this seems like it might be useful in
other cases as well.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Gamepad API [Was: New feature flag proposal: Joystick API]

[Michael Nordman]

Its obvious that a naming nit is a not a good reason to block development
behind a flag.

Is the the true basis for that r- expressed in this comment?
"The concern here as I understand it is that providing low level access to
every possible controller creates fragmentation, with purportedly "HTML"
content that only works on a few devices. There is no clear cut border here
- it's been mentioned that even touch events can be seen as rare - and then
I advocate that adding more mouse specific events is a bad idea for the same
reason."


But that concern also shouldn't block initial development behind a flag.
Seems like that concern should be brought up with the WG.



On Wed, Oct 12, 2011 at 12:59 PM, Darin Fisher  wrote:

> Hi all,
>
> Alexey appears to strongly dislike the name of this API specification (
> http://dvcs.w3.org/hg/webevents/raw-file/default/gamepad.html), so much so
> that he is blocking development of the API behind a flag.
>
> As a reminder, this API is being developed through the WebEvents WG jointly
> with other browser vendors, including Mozilla.  Folks working on this appear
> to be content with the Gamepad name, precisely because the spec is limited
> to dealing with input devices that are represented in terms of buttons and
> axes.  Gamepad seems like a fairly canonical name for such a device, even
> though devices by other names can be represented by similar data.
>
> Does anyone else feel strongly enough that the name of the API is so bad
> that it should therefore not be allowed onto WebKit trunk behind a flag?
>
> Personally, I feel like the name is quite malleable at this point in time,
> and I really like coming up with the best possible name for things.
>  However, I don't see why we need to have the perfect name before we
> continue development of this feature behind a flag.
>
> As we were developing Blob and File support, we made several name changes
> along the way.  It is not always so obvious how to name things from the
> start.
>
> See this bug for reference:
> https://bugs.webkit.org/show_bug.cgi?id=69451
>
> Thoughts?
> -Darin
>
>
> On Thu, Oct 6, 2011 at 2:07 PM, Alexey Proskuryakov  wrote:
>
>>
>> 06.10.2011, в 13:49, Scott Graham написал(а):
>>
>>  The first revision of the spec (from the Scope section) is intended to
>> handle:
>>
>> ... support for devices common to current gaming systems including
>> gamepads, directional pads, joysticks, wheels, pedals, accelerometers.
>>
>>
>> Why does the spec title and abstract talk about gamepads (joysticks)
>> only? Perhaps it's my mistake that I didn't read the scope section, but with
>> title and abstract being so specific, that seemed unnecessary.
>>
>> Skipping scope section, I went right to IDL. Why is the interface called
>> Gamepad if it's not only about gamepads?
>>
>>  - WBR, Alexey Proskuryakov
>>
>>
>> ___
>> 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] DOMCrypt

[Michael Nordman]

I think bytes and blobs would be sufficient.

+f...@google.com

On Fri, Aug 5, 2011 at 12:58 PM, Adam Barth  wrote:

> Bytes and (likely) blobs are types we're planning to do in DOMCrypt.
> Hashing strings is slightly more delicate because you need to pick an
> encoding.  Do you have a sense, if we did bytes and blobs, would that
> be enough, or are strings really important also?
>
> Thanks,
> Adam
>
>
> On Fri, Aug 5, 2011 at 12:43 PM, Michael Nordman 
> wrote:
> > Yes, hashing blobs. Here's the last line of the relevant meeting notes...
> > "In the end, we all agreed that the main thing with the highest utility
> > would be a native hashing implementation that could accept strings,
> bytes,
> > or BLOBs."
> >
> > On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth  wrote:
> >>
> >> On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman 
> >> wrote:
> >> >> For example, the CryptoHash
> >> >> interface can be implemented independently of the rest of the API and
> >> >> provides value by itself.
> >> >
> >> > Moving forward on that part first sounds reasonable. I've been asked
> >> > about
> >> > that specifically by some app developers that really aren't interested
> >> > in
> >> > the other parts of the larger proposal.
> >>
> >> Are they specifically interested in hashing blobs?  David and I have
> >> been discussing what sort of types these functions should handle.
> >>
> >> Adam
> >>
> >>
> >> > On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig 
> wrote:
> >> >>
> >> >> I think we should let the spec mature a bit before diving in.
> >> >>
> >> >> -Sam
> >> >>
> >> >> On Jul 26, 2011, at 10:53 PM, Adam Barth wrote:
> >> >>
> >> >> > Hi webkit-dev,
> >> >> >
> >> >> > As some of you are probably aware, Mozilla is experimenting with
> >> >> > exposing some basic cryptographic primitives to web applications:
> >> >> >
> >> >> > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> >> >> >
> >> >> > I wanted to get a sense from the WebKit community about how
> >> >> > interested
> >> >> > we are in implementing this feature.  My sense is that this API is
> >> >> > fairly early in it's lifecycle, so one perspective is that we
> should
> >> >> > wait for Mozilla to experiment for a bit longer and revisit this
> >> >> > question once the design is further along (e.g., submitted to the
> W3C
> >> >> > standards process).
> >> >> >
> >> >> > Another perspective is that there are some simple parts of the API
> >> >> > that we should implement now, and we can grow into the more
> involved
> >> >> > parts of the API as they mature.  For example, the CryptoHash
> >> >> > interface can be implemented independently of the rest of the API
> and
> >> >> > provides value by itself.
> >> >> >
> >> >> > Thoughts?
> >> >> >
> >> >> > Adam
> >> >> > ___
> >> >> > 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] DOMCrypt

[Michael Nordman]

Yes, hashing blobs. Here's the last line of the relevant meeting notes...

"In the end, we all agreed that the main thing with the highest utility
would be a native hashing implementation that could accept strings, bytes,
or BLOBs."

On Fri, Aug 5, 2011 at 12:32 PM, Adam Barth  wrote:

> On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman 
> wrote:
> >> For example, the CryptoHash
> >> interface can be implemented independently of the rest of the API and
> >> provides value by itself.
> >
> > Moving forward on that part first sounds reasonable. I've been asked
> about
> > that specifically by some app developers that really aren't interested in
> > the other parts of the larger proposal.
>
> Are they specifically interested in hashing blobs?  David and I have
> been discussing what sort of types these functions should handle.
>
> Adam
>
>
> > On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig  wrote:
> >>
> >> I think we should let the spec mature a bit before diving in.
> >>
> >> -Sam
> >>
> >> On Jul 26, 2011, at 10:53 PM, Adam Barth wrote:
> >>
> >> > Hi webkit-dev,
> >> >
> >> > As some of you are probably aware, Mozilla is experimenting with
> >> > exposing some basic cryptographic primitives to web applications:
> >> >
> >> > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> >> >
> >> > I wanted to get a sense from the WebKit community about how interested
> >> > we are in implementing this feature.  My sense is that this API is
> >> > fairly early in it's lifecycle, so one perspective is that we should
> >> > wait for Mozilla to experiment for a bit longer and revisit this
> >> > question once the design is further along (e.g., submitted to the W3C
> >> > standards process).
> >> >
> >> > Another perspective is that there are some simple parts of the API
> >> > that we should implement now, and we can grow into the more involved
> >> > parts of the API as they mature.  For example, the CryptoHash
> >> > interface can be implemented independently of the rest of the API and
> >> > provides value by itself.
> >> >
> >> > Thoughts?
> >> >
> >> > Adam
> >> > ___
> >> > 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] DOMCrypt

[Michael Nordman]

> For example, the CryptoHash
> interface can be implemented independently of the rest of the API and
> provides value by itself.

Moving forward on that part first sounds reasonable. I've been asked about
that specifically by some app developers that really aren't interested in
the other parts of the larger proposal.

On Wed, Jul 27, 2011 at 10:06 AM, Sam Weinig  wrote:

> I think we should let the spec mature a bit before diving in.
>
> -Sam
>
> On Jul 26, 2011, at 10:53 PM, Adam Barth wrote:
>
> > Hi webkit-dev,
> >
> > As some of you are probably aware, Mozilla is experimenting with
> > exposing some basic cryptographic primitives to web applications:
> >
> > https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
> >
> > I wanted to get a sense from the WebKit community about how interested
> > we are in implementing this feature.  My sense is that this API is
> > fairly early in it's lifecycle, so one perspective is that we should
> > wait for Mozilla to experiment for a bit longer and revisit this
> > question once the design is further along (e.g., submitted to the W3C
> > standards process).
> >
> > Another perspective is that there are some simple parts of the API
> > that we should implement now, and we can grow into the more involved
> > parts of the API as they mature.  For example, the CryptoHash
> > interface can be implemented independently of the rest of the API and
> > provides value by itself.
> >
> > Thoughts?
> >
> > Adam
> > ___
> > 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] The http tests are very flaky

[Michael Nordman]

lighttpd+cgiphp is not super reliable... i think that accounts for
some amount of chromium's http test flakiness on windows.

On Fri, Jan 14, 2011 at 10:07 AM, Julie Parent  wrote:
> For Chromium, the http tests aren't very flaky on Mac (I see only 5 flaky
> http tests).  Windows, however, is another story.
>
> On Fri, Jan 14, 2011 at 8:54 AM, Ojan Vafai  wrote:
>>
>> On Thu, Jan 13, 2011 at 11:10 PM, Eric Seidel  wrote:
>>>
>>> Looking at the Chromium Flakiness dashboard (which has results going
>>> back for months!) we see that many of the same http tests are flaky
>>> for chromium too:
>>> http://test-results.appspot.com/dashboards/flakiness_dashboard.html
>>>
>>> I believe they use a different http server (lighttpd, but my
>>> information could be old?) and certainly a separate network stack.
>>
>> We use lighttpd only on Windows. It's been on our long-term TODO list to
>> use apache on Windows again, but getting it to work on Vista/Win7 has proven
>> tricky.
>> Ojan
>> ___
>> 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] XHR responseArrayBuffer attribute

[Michael Nordman]

Webkit's XHR currently does not keep two copies of the data that I can see.
I think we should avoid that.

On Mon, Sep 27, 2010 at 2:40 PM, Anne van Kesteren <
annevankeste...@gmail.com> wrote:

> (I'm subscribed to webkit-dev with a different address.)
>
> On Mon, Sep 27, 2010 at 8:31 PM, Michael Nordman 
> wrote:
> > Yes, if we go with telling xhr up front for the array buffer case, I
> guess
> > an enum would be slightly better.
>
> I do not think this should be told up front. You already need to keep
> the octet buffer in memory for overrideMimeType to work the way it
> does. We designed responseBlob as an optimization so you would not
> have to deal with the other types. I do not think you can optimize the
> reverse with the design as it stands today.
>
> In any event, any discussion on changes to the specification really
> ought to happen on public-weba...@w3.org.
>
> Cheers,
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] XHR responseArrayBuffer attribute

[Michael Nordman]

Yes, if we go with telling xhr up front for the array buffer case, I guess
an enum would be slightly better.

On Fri, Sep 24, 2010 at 8:39 PM, Chris Rogers  wrote:

> If we added xhr.asArrayBuffer, what would happen if xhr.asBlob was also
> set?  Don't we really want something like xhr.loadAsType with different enum
> values for text, blob, array buffer, etc.?
>
> On Fri, Sep 24, 2010 at 5:19 PM, Michael Nordman wrote:
>
>> With xhr.responseBlob we chose to have the caller decide up front and tell
>> the xhr object how it would like the response by setting the xhr.asBlob
>> attribute prior to calling send(). We could do the same with
>> xhr.asArrayBuffer.
>>
>> On Fri, Sep 24, 2010 at 5:09 PM, Alexey Proskuryakov wrote:
>>
>>>
>>> 24.09.2010, в 16:37, Chris Rogers написал(а):
>>>
>>> > I was interested to know if anybody was planning on implementing that
>>> attribute soon.  If not, I would like to add this myself.
>>>
>>> The key problem to solve is how to not double the memory use of the
>>> XMLHttpRequest object, while not making responseText and responseXML slow.
>>>
>>> See also: <https://bugs.webkit.org/show_bug.cgi?id=40954>. Do we need
>>> both responseBody and responseArrayBuffer?
>>>
>>> - WBR, Alexey Proskuryakov
>>>
>>> ___
>>> 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] XHR responseArrayBuffer attribute

[Michael Nordman]

With xhr.responseBlob we chose to have the caller decide up front and tell
the xhr object how it would like the response by setting the xhr.asBlob
attribute prior to calling send(). We could do the same with
xhr.asArrayBuffer.

On Fri, Sep 24, 2010 at 5:09 PM, Alexey Proskuryakov  wrote:

>
> 24.09.2010, в 16:37, Chris Rogers написал(а):
>
> > I was interested to know if anybody was planning on implementing that
> attribute soon.  If not, I would like to add this myself.
>
> The key problem to solve is how to not double the memory use of the
> XMLHttpRequest object, while not making responseText and responseXML slow.
>
> See also: . Do we need both
> responseBody and responseArrayBuffer?
>
> - WBR, Alexey Proskuryakov
>
> ___
> 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] Blob scheme implementation

[Michael Nordman]

On Wed, Sep 15, 2010 at 9:15 AM, Darin Fisher  wrote:

> On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov wrote:
>
>>
>> 14.09.2010, в 22:15, Darin Fisher написал(а):
>>
>> > I think it makes sense to extend ResourceHandle.cpp to access the
>> BlobRegistry singleton in order to support blob URLs.
>>
>>
>> The problem I see with adding blob support to ResourceHandle is that it
>> makes it too difficult to maintain. It used to be a platform abstraction,
>> and it was hard enough to make sure it worked well across platforms. Adding
>> a significant amount of cross-platform logic on top of that isn't going to
>> make it easier - especially when it's done via subclassing.
>>
>
> I don't understand why this seems so complicated.  ResourceHandle.cpp
> contains some code that is shared by all WebKit ports that can access their
> network stack directly from the WebKit main thread.  It already has some
> common code for handling certain error cases (invalid URL, bad port).  This
> is the best point in the code to integrate blob URL support.
>
> Maybe subclassing ResourceHandle is not the best way to go about this.  It
> seems fairly clean to me, but then, I'm not sure what the alternative
> proposals look like.
>
>
>
>>
>> An example that prompted me to look into this was <
>> http://trac.webkit.org/changeset/67503>. Here, a static function that
>> reported platform capabilities had to become virtual, so that it could take
>> blob loading logic into account. There is nothing in common between "are we
>> running on a version of Mac OS X that supports this" and "are we loading a
>> blob", and remembering this twist won't be easy.
>>
>
> Perhaps the static function should remain but be renamed?  That way it can
> remain the function that reports platform capabilities.  However, as this
> patch demonstrates, from WebCore's point of view, this needs to be a
> property of ResourceHandle.
>
> Maybe it would help if we better formalized the abstraction to the network
> stack and let ResourceHandle grow to be a smart (contains cross-platform
> helper code) front-end to that.
>

+1 "Maybe it would help if we better formalized the abstraction to the
network stack and let ResourceHandle grow to be a smart (contains
cross-platform helper code) front-end to that."

AppCache loading has been mentioned a couple times in this thread. Really,
the points of integration between the loader and the appcache are mostly
smoke and mirrors in chrome... loading out of an appcache actually happens
via ResourceHandle in our port. Webcore's webarchive loading wouldn't work
in a sandboxed renderer either.

I'm working up to a similar 'where to put what code' conundrum around
xhr.responseBlob. Ideally, I'd like ResourceHandle to produce the blob.

ResourceHandle vs PlatformResourceHandle, maybe a class like the latter
could have a 'capabilities' interface that allowed common code to query
things like 'CanProvideResponseBlobs' and if not provides that capability in
common code. Similarly a 'CanHandleBlobScheme' capability query could
provide a fork in the road for loading blob urls (so the common code impl
would poke at the BlobRegistry singleton).

Subclassing ResourceHandle for blob url loading is probably not the most
elegant thing, but given the current state of the code base,  it's not a bad
option.

This schism around ResourceHandle in particular is a recurring theme. The
recurring answer "do it in the loader" just doesn't work so well for us.


>
> -Darin
>
> ___
> 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] How to handle a new protocol for Blob.url support?

[Michael Nordman]

Does webcore have a 'protocol handler' abstraction that can be leveraged to
add support for a new protocol scheme?  I don't think it does, but an
abstraction like that may help with this.

On Wed, Jun 2, 2010 at 6:19 PM, Jian Li  wrote:

> This will probably work for most of the platforms, except the one that uses
> multi-process architecture. How do we handle the case that a page is trying
> to access a blob URL that is created in another process (assume the
> accessing page is in the same security domain)? I think for the platform,
> like Chromium, we can choose to delegate to the host to do the right job,
> while all other platforms will share the same handling logic defined at a
> higher level.
>
> In addition, we might need to hook up additional logic if we want to
> support using it in the shared worker process.
>
>
>
> On Wed, Jun 2, 2010 at 6:08 PM, Darin Adler  wrote:
>
>> On Jun 1, 2010, at 5:14 PM, Jian Li wrote:
>>
>> I am working on Blob.url support as defined in the latest version of File
>> API (http://dev.w3.org/2006/webapi/FileAPI/). The Blob.url will return a
>> URL that can be used to refer to the blob object in a resource request, like
>> blobdata:f81d4fae-7dec-11d0-a765-00a0c91e6bf6. The blob object can represent
>> a whole file, a partial file (created by Blob.slice), or a byte array
>> (created by BlobBuilder defined in the FileWriter spec). What is the right
>> place I can hook up with in order to interpret and process the blobdata
>> request? Should it be in the WebKit library layer that will be implemented
>> by individual platform or in the higher layer like what application cache
>> does the work?
>>
>>
>> Definitely a higher level. We don’t want to have to reimplement a feature
>> like this for each platform.
>>
>> -- Darin
>>
>>
>
> ___
> 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] MD5 in WebCore

[Michael Nordman]

In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows and md5.cc elsewhere?

For chrome, I don't think we can have a dependency between
WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
doesn't work. How can we avoid replicating the code? I guess having
webcore's MD5 be platform specific could help us along those lines?


On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak  wrote:

>
> On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
>
> I'm implementing new protocol of WebSocket (
> http://www.whatwg.org/specs/web-socket-protocol/ ).
> Since it now requires MD5 in handshake, I wonder how I could add MD5 in
> WebCore.  For now, there is no MD5 in WebCore.  It is in
> WebKitTools/DumpRenderTree to get message digest of image file.
>
> I'm thinking to add new header file as WebCore/platform/MD5.h, which
> provides the following functions.
>
>   struct MD5_CTX;
>   void MD5_Init(MD5_CTX*);
>   void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
>   void MD5_Final(unsigned char hash[16], MD5_CTX*);
>
> In Windows platform, it is implemented using "Cryptdll.dll".   Is it ok to
> copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
> or move?
> In Mac platform, it is provided by  with
> #define COMMON_DIGEST_FOR_OPENSSL ?
> In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy this in
> WebCore/platform/chromium, or add dependency to base from WebCore?
> How about other ports?  is it ok to link openssl or some other library?
>  (or use implementation used in chromium?)
>
> I'm also wonder I need to put these functions in namespace WebCore.
>
>
> If you put this code in WebCore, it should go in the WebCore namespace. I
> think it would also be a good idea to turn the API into something more
> WebCore-ish, something like:
>
> namespace WebCore {
>
> class MD5 {
> MD5(); // what was MD5_Init
> addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
> or maybe this should take a Vector?
> Vector checksum(); // what was MD5_Final
> };
> }
>
> (The key point being to match the coding style guidelines for names, but it
> also seems better to use a class here instead of a struct and functions that
> take a pointer to it.)
>
> 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] WTF::callOnMainThread() and re-entrancy

[Michael Nordman]

On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov  wrote:

>
> On 09.03.2010, at 9:45, Drew Wilson wrote:
>
>  Yeah, it's a race condition - it seems to all depend on whether the worker
>> resource gets loaded before the postMessage loop starts. Failure rate is
>> around 30-50% on my machine.
>>
>
> It would help to have a more detailed description of the problem. I've been
> following the discussion in bugs and in this thread, but I'm still unsure
> about some aspects of it.
>
> Seems that there are two issues at hand:
>
> 1) We feel the need to change how Document::postTask() behaves, because
> otherwise, the patch for 
> doesn't work. We feel the need because it makes little sense for it to have
> drastically different behavior depending on what thread it's called from.
>
> It feels like a good change to make indeed, but I'm surprised that it
> apparently went through review unmentioned and unquestioned. The questions
> to ask are why exactly it was needed, and whether there are other ways to
> fix bug 34726.
>

This was discussed somewhat off list between dumi, dimich, and myself (and
whomever else dumi traded notes with). We were very surprised that tasks
scheduled via postTask() were not executed in the same order as being
scheduled. This change to postTask() was a shot at remedying that... but low
and behold, something was apparently depending on the out of order
execution?


>
> 2) if we make that change, the worker-cloneport.html test starts to fail.
>
> I didn't attempt to debug this myself, and I don't quite understand the
> problem description. I see only one postMessage loop in the test, and it's
> in worker code. How can it be executed before the worker resource gets
> loaded?
>
>
>  It looks like events have priority in Cocoa, and I'm guessing that
>> performSelectorOnMainThread() creates events with a higher priority than
>> those generated by URLConnection, which can lead to starvation. I'm not
>> certain what the right fix is, other than to maybe use a different method of
>> dispatching events other than performSelectorOnMainThread that lets us set a
>> lower priority?
>>
>
> These main thread calls do not use events for processing. CF/NSRunLoop has
> a concept of run loop sources, which can generate events or perform other
> actions, see <
> http://developer.apple.com/mac/library/documentation/CoreFoundation/Reference/CFRunLoopRef/Reference/reference.html>
> and <
> http://developer.apple.com/Mac/library/documentation/CoreFoundation/Reference/CFRunLoopSourceRef/Reference/reference.html
> >.
>
>
> - WBR, Alexey Proskuryakov
>
> ___
> 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] Question on FormData interface and implementation

[Michael Nordman]

option 3: We could name any new classes backing the new scriptable object as
DOMFormData (similar in sprirt to DOMWindow), and leave the existing
FormData classes as they are.

On Thu, Feb 25, 2010 at 3:31 PM, Jian Li  wrote:

> Hi,
>
> I am looking into the work to support FormData interface as defined in
> XMLHttpRequest Level 2 (
> http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#formdata). To support the
> new FormData interface, we need to add the FormData object that collides
> with the name that has already existed. Currently we already have FormData
> and FormDataElement that encapsulate the formalized data to send out. How
> are we going to resolve the naming issue?
>
> Approach 1: we can try to merge the current version of FormData with the
> new functionalities in the to-be-added FormData. This means that the new
> version will handle both raw key-value-pair FormData and formalized
> FormData. It seems to be a little bit messy, IMHO.
>
> Approach 2: we can rename the current version of FormData to something like
> FormalizedFormData or FormSendingData that keeps all the current logic to
> represent the formalized data to send out. We then use FormData for the new
> FormData interface, that represent the raw key-value-pair list, just like
> FormDataList. Indeed we will merge FormDataList into this new version of
> FormData.
>
> How do you guys think?
>
> Thanks,
>
> Jian
>
>
> ___
> 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] SharedScript: next steps and result of offline discussion.

[Michael Nordman]

> Saving a subsite of live script and DOM objects across a full page load
does not seem useful to me

Lots of sites use actual frame navigations to navigate.

On Tue, Dec 15, 2009 at 12:06 PM, Maciej Stachowiak  wrote:

>
> On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote:
>
>
>
> On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher  wrote:
>
>> I think that use case has been de-emphasized.  However, if we wanted to
>> support it, we'd probably have to say that removeChild of an IFRAME element
>> doesn't cause the unload event to be dispatched.  (I'm a bit concerned that
>> that may cause incompatibilities with existing pages.)  Then, you'd have to
>> store a reference to the IFRAME element in a global variable, so that you
>> could find it again when the next document is loaded.
>
>
> I hope this use-case can be accommodated, I think this is ultimately the
> more generally applicable use-case. Btw, concern for incompatibilities with
> existing pages was one reason we came up with a new construct for this
> capability (instead of overloading  or 

Re: [webkit-dev] SharedScript: next steps and result of offline discussion.

[Michael Nordman]

On Mon, Dec 14, 2009 at 9:16 PM, Darin Fisher  wrote:

> I think that use case has been de-emphasized.  However, if we wanted to
> support it, we'd probably have to say that removeChild of an IFRAME element
> doesn't cause the unload event to be dispatched.  (I'm a bit concerned that
> that may cause incompatibilities with existing pages.)  Then, you'd have to
> store a reference to the IFRAME element in a global variable, so that you
> could find it again when the next document is loaded.


I hope this use-case can be accommodated, I think this is ultimately the
more generally applicable use-case. Btw, concern for incompatibilities with
existing pages was one reason we came up with a new construct for this
capability (instead of overloading  or 

Re: [webkit-dev] SharedScript: next steps and result of offline discussion.

[Michael Nordman]

How does reparenting across in-place frame navigations work in this scheme?
Is a de-parented iframe guaranteed to linger long enough for the new page to
get it by name and re-parent it if desired?

On Thu, Dec 3, 2009 at 7:01 PM, Dmitry Titov  wrote:

> Hi WebKit,
>
> The recent discussion indicated there is a feeling that SharedScript
> functionality can be achieved by other means that do not require adding new
> big APIs: changing iframe a bit (so it's internals survive reparenting into
> another document) and adding single getWindowByName() API.
>
> Ian Hickson proposed this idea noting that nothing in the spec prevents
> iframe from staying alive over the reparenting.  Some folks from Google met
> with folks from Apple to discuss and it appears there is a consensus that we
> shall remove initial code for SharedScript and instead implement changes for
> iframe and getWindowByFrame(). This will not cause new API and hopefully
> won't cause compatibility issues since the only scenario that will behave
> differently is reparenting of the iframe between documents that is hopefully
> a rare thing. Perhaps more discussion will be needed to nail details on
> those.
>
> Separately (or related?), we discussed SharedWorkers and the way XHR works
> in them. It seems a good idea to investigate a "shadow document' solution
> (as Chrome does for worker processes) when a dummy document is created and
> used to load resources on behalf of the worker. Also we'll try to fix couple
> of bugs that prevent Workers to be reliable enough.
>
> Thanks a lot to all who chimed in and helped to arrive to a good solution
> to the same issues that SharedScript was trying to solve! :-)
>
> Dmitry Titov
>
>
>
> ___
> 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] Database in Worker context

[Michael Nordman]

>  not clear to me what benefit could be had by effectively splitting a
class in two

Perhaps more easily worked on by multiple hands in parallel with fewer
conflicts. Various bits of "database stuff" are better encapsulated in
database specific classes (so maybe easier to learn how the system works
when code snorkling).

Either way would work of course, the direction eric's heading seems like a
clean way to factor things.


On Thu, Dec 10, 2009 at 11:09 AM, Eric Uhrhane  wrote:

> On Wed, Dec 9, 2009 at 6:55 PM, Dmitry Titov  wrote:
> > Thanks for the link to the prototype code!
> > If I understand it right and the DatabaseManager can not have any other
> > relationship with ScriptExecutionContext but 1-1 and their lifetime is
> the
> > same then it's not clear to me what benefit could be had by effectively
> > splitting a class in two. The fact that DatabaseManager is RefCounted
> also
> > hints that some other object could take ownership of it as well outside
> of
> > lifetime of ScriptExecutionContext, but is this true?
>
> That's there because the DatabaseThread [and therefore the Database]
> can stick around for a bit after the ScriptExecutionContext is deleted
> if I make it non-refcounted.  If I move the DatabaseManager parts into
> the ScriptExecutionContext, then I have to make sure that the SEC
> sticks around until after the Database and DatabaseThread have gone
> away.
>
> I can do that--the benefit I thought I was getting wasn't one of
> object lifetime.  I just thought the classes were cleaner this way.
> But if you really think it's better to have it all in together, I can
> certainly move it.
>
> > ScriptExecutionContext collects functionality common for Workers and
> > Documents, and as such is a home for a few 'groups' of methods, like a
> few
> > methods to deal with MessagePorts. MessagePort, in turn, has a raw
> pointer
> > back to ScriptExecutionContext - so it's clear that MessagePorts do not
> > outlive the SEC. Same pattern could be used for
> > ScriptExecutionContext/Database, for consistency. It also simplifies
> design
> > a bit - no need for a special refcounted manager class, and things
> > like callOnJavaScriptThread could be replaced by SEC::postTask() which is
> > already implemented.
>
> The point of CallOnJavascriptThread is that the JS thread is the Main
> Thread in the Document context, but [in Chromium's implementation] NOT
> in the Worker context.  I needed a virtual method to distinguish
> between the two cases, since the Database code previously treated
> isMainThread as synonymous with isJavascriptThread.  But of course
> that virtual method can be moved to Document and SEC instead of DDM
> and WDM.
>
> > On Wed, Dec 9, 2009 at 5:21 PM, Eric Uhrhane  wrote:
> >>
> >> On Wed, Dec 9, 2009 at 4:11 PM, Dmitry Titov 
> wrote:
> >> > On Wed, Dec 9, 2009 at 12:58 PM, Eric Uhrhane 
> >> > wrote:
> >> >>
> >> >>  I've pulled the database-related members out of Document and made a
> >> >> new class for them, DatabaseManager.  An instance of that is owned by
> >> >> each ScriptExecutionContext.  There are two flavors,
> >> >> DocumentDatabaseManager and WorkerDatabaseManager.  They're not very
> >> >> different, but in a few cases it was necessary to distinguish between
> >> >> them
> >> >
> >> > I don't see your code, just generic thought: If those classes are
> small,
> >> > then perhaps ScriptExecutionContext could absorb a couple of methods
> to
> >> > deal
> >> > with that? Some of them could be virtual and implemented differently
> on
> >> > Document and WorkerContext.
> >> > Dmitry
> >>
> >> You don't see the code because I sent this as an early
> >> warning--there's nothing checked in yet.
> >> The classes aren't huge, and in fact most of the code was in Document
> >> before, but given that it's all to do with a separable concept [the
> >> Database], I thought it nicer to pull it out.  Let's
> >> see...DatabaseManger.cpp is 172 lines [including copyright headers,
> >> etc.] and the header is 107.  Seems like a lot to sprinkle through
> >> ScriptExecutionContext, Database, and WorkerContext.  You can take a
> >> look at my current code [where I'm backing it up--this won't actually
> >> be sent for review from this repository] at
> >> http://codereview.chromium.org/401016/show [mostly storage + v8
> >> bindings] and http://codereview.chromium.org/464018/show [mostly
> >> Chrome browser process stuff] and see what you think.
> >>
> >> Thanks,
> >>
> >> Eric
> >
> >
> > ___
> > 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] Proposing style guide change regarding braces on conditional arms

[Michael Nordman]

what peter pitched and what mjs pitched are one and the same i think

* When all arms of a conditional or loop are one physical line, do not use
braces.  If any arms are more than one physical line (even if they are one
logical line), use braces on all arms.

 One possible conservative modification to the rule is that if you have a
>>> multi-block if ... else if ... else chain, then if even one body has braces,
>>> all should. I think that would tend to reduce rather than increase visual
>>> noise, as all the "else" keywords would line up where right now they look
>>> ragged.
>>
>>
+1
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] localStorage quota limit

[Michael Nordman]

Arguably, seems like a bug that invalid string values are let thru the door
to start with?

Since users can't effectively store invalid UTF16 character sequences in FF
or IE, is there really any downside to using UTF8 text encoding in WebKit?
@Jeremy, this isn't a matter of letting users choose the text encoding, this
is entirely an implementation detail of WebStorage.

Downsides
* The code change to get UTF8 by default in new databases, tiny.
* Migrating pre-existing databases to the new encoding. Somewhat of a
hassle. But maybe doesn't need to be done, pre-existing files could continue
to use UTF16, while newly created dbs could use UTF8 (the text encoding is
chosen at database creation time and stuck that way forever thereafter).
* Its possible that some app is already depending on the ability to store
invalid character sequences (on the iPhone say), and this would be a
breaking change for that app.

The preload everything characteristic is a separate issue altogether.



On Wed, Dec 2, 2009 at 11:15 AM, Jeremy Orlow  wrote:

> IE chokes ("invalid procedure call or argument") and Firefox mangles the
> data for LocalStorage (but works fine for SessionStorage).
>
> On Wed, Dec 2, 2009 at 10:54 AM, Darin Adler  wrote:
>
>> On Dec 2, 2009, at 10:48 AM, Jeremy Orlow wrote:
>>
>> > How can you construct invalid UTF-16 sequences?
>>
>> http://unicode.org/faq/utf_bom.html#utf16-7
>>
>>-- Darin
>>
>>
>
> ___
> 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] localStorage quota limit

[Michael Nordman]

Could WebKit configure the localstorage database(s) to use UTF8 text
encoding for string values?

On Sun, Nov 29, 2009 at 8:38 AM, William Edney
wrote:

> All -
>
> I've been discussing the localStorage quota limit over on this bug with
> Jeremy Orlow:
>
> https://bugs.webkit.org/show_bug.cgi?id=31791
>
> To recap from the discussions on that bug:
>
> Jeremy has implemented the localStorage quota on the latest Webkit builds.
> This caused my usage of localStorage to fail, because as a JS programmer, I
> assumed that 5MB meant '5 million characters' of storage. This assumption
> holds true on Firefox 3.5.X+ and IE8, but fails on Webkit since it stores
> things into localStorage as UTF-16.
>
> One option we discussed on that bug was getting the spec folks to alter the
> spec in one of three ways:
>
> - specify the quota in terms of 'characters' (or Strings, or whatever)
> thereby abstracting away the encoding problem entirely.
> - specify UTF-8 so that 'MB = characters'
> - specify a JS API such that the encoding could be specified.
>
> Jeremy wasn't too taken with any of these proposals, and in any case, they
> probably need to be taken up on the W3 group defining this stuff, not here.
>
> In any case, as Jeremy states in Comment #5 of the bug report, "the spec's
> mentioning of 5mb is really just an example". And when I filed this bug on
> Mozilla's Bugzilla tracker:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=461684
>
> another comment there points out the same thing. (Note that this bug was
> originally filed to see if the Mozilla guys would raise their quota to 10MB
> to match IE8 and, since they don't use double-byte encoding, I was really
> asking for '10 million characters' there :-)).
>
> Given that, an increase from 5MB to 10MB would 'solve my immediate
> problem'. And, without going back to the spec folks, I'm not sure that much
> more can be done here.
>
> Jeremy wanted me to post to get the discussion started (and hopefully
> attain some consensus :-) ), so let's discuss :-).
>
> Thanks in advance!
>
> Cheers,
>
> - Bill
>
> ___
> 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] GlobalScript in WebKit

[Michael Nordman]

Just to provide some history...

An intrinsic aspect of the SharedScript proposal is that scripting across
the page / sharedScript boundary should be very fast. When coming up with
the original proposal, we were careful to not require "singleton" semantics
that would work against that goal (by requiring ipc proxy'ing and thread
synchronization).

A "common context for all instances of a page" was intentionally not a goal
since to make that gaurantee would be very much at odds with the performance
goal.

We tried to strike that balance between the scope of sharing and the promise
of being performant by saying all pages within a "unit of related browsing
contexts" are guaranteed to shared the same SharedContexts. In our proposal,
the scope of shared is permitted to be wider, but is not required to be
wider.

A secondary concern is co-locating top-level pages to widen the scope of
sharing beyond just the "unit of related browsing contexts". We've hand
waved at "hints" that could help the browser accomplish that.



On Tue, Dec 1, 2009 at 12:20 PM, Ian Hickson  wrote:

> On Tue, 1 Dec 2009, Michael Davidson wrote:
> > On Tue, Dec 1, 2009 at 11:51 AM, Ian Hickson  wrote:
> > > On Tue, 1 Dec 2009, Michael Davidson wrote:
> > > > No, we definitely want to share network connections. We'd like users
> > > > to be able to have an arbitrary number of Gmail windows open without
> > > > running into the browser connection limit.
> > >
> > > SharedScript doesn't give you that. Only a singleton mechanism can
> > > give you that.
> >
> > Assuming that the same-process hinting works, it will give us that.
>
> The process hinting is not a guarantee. It is trivial to come up with
> situations where different documents from the same origin are required to
> end up in different processes. Furthermore, as a user, I would personally
> much rather every GMail instance I open end up in a different process, for
> the same reason that I'd like GMail and Google Calendar in different
> instances, and Google Calendar and Google Search in different processes,
> and Search and pages I get to from Search in different processes.
>
>
> > At the very least, it will vastly improve the situation we have today.
>
> Either you "definitely want to share network connections", in which case
> it doesn't give you what you want, or you don't need to share network
> connections, in which case it seems no better than an .
>
>
> > The iGoogle gadget that you mention later would not use SharedScript,
> > FWIW.
>
> Sure, but if it opens a true GMail window, that GMail window would have to
> end up in the same process as the parent (so that the opener can be
> accessed), which means it wouldn't be the same process as other GMail
> tabs. It doesn't have to be an iGoogle gadget; any page that
> window.open()s GMail would be in this situation as far as I can tell.
>
>
> > I agree that anything that lives in an iframe is going to cause problems
> > for SharedScript, but Gmail (like many webapps where having the URL
> > exposed to the user is very important) doesn't allow itself to be in an
> > iframe.
>
> It prevents it using script, which is too late since the process selection
> happens long before the script runs.
>
>
> > > It seems that you could just create an  instead of the
> > > SharedScript, and pass it around onunload.
> >
> > Can an iframe live independently of its creating document?
>
> Per spec, yes, so long as it is owned by a living document it'll keep
> existing. It should even work in browsers so long as you actually keep the
> iframe grafted to an existing Window's Document -- hence the "pass it
> around onunload" to keep it alive.
>
>
> > The goal is not to mislead people into thinking that SharedScript is
> > bulletproof sharing, which is why the spec says that sharing might fail.
>
> Yes, but people will think that's what it does, regardless of what it
> does, because in most testing that's what it will do. It's like the
> localStorage debacle -- we have to offer consistency guarantees because
> people will assume them regardless of what the spec says.
>
>
>
> Anyway, I'm not trying to discourage experimentation here; I just wanted
> to make it clear that SharedScript doesn't solve the shared networking
> problem, because it can never be guarenteed to be a singleton -- indeed,
> from the user's perspective, it would be undesireable for it to be
> possible to make the browser always put all tabs from one origin into the
> same process even if it was possible.
>
> --
> Ian Hickson   U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> ___
> 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.web

Re: [webkit-dev] GlobalScript in WebKit

[Michael Nordman]

http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
What a great rant :)

I'm also reminded of this quote...
"The reasonable man adapts himself to the world. The unreasonable man
persists in trying to adapt the world to himself. Therefore, all progress
depends on the unreasonable man." -George Bernard
Shaw

The Chrome team has come around to putting this particular feature into
Chrome as an experiment. It's not clear that can be pulled off without
actually putting some bits into WebKit, and I think we're of the opinion
that the cleanest implementation is to have the code reside entirely in
WebKit. (Personally, I think to do otherwise puts us into the realm of
hackery  to pull off the experiment.)

Sam said "It adds extra complexity to WebKit". We can and should keep a
careful eye to minimize that.


On Mon, Nov 30, 2009 at 9:55 AM, Dimitri Glazkov wrote:

> Reading this, I am reminded of a great commentary by Alex Russell,
> written nearly 3 years ago:
>
> http://alex.dojotoolkit.org/2007/12/the-w3c-cannot-save-us/
>
> Despite of what I may think about SharedScript, I am certain that
> waiting -- whether for standards community or Web developers to
> embrace or reject our ideas -- is not the right answer. If we really
> want to move the Web platform forward, we can't afford a feedback
> cycle this long. Especially, when we have an opportunity for close
> collaboration with Web developers of some of the most JS-intensive Web
> properties.
>
> Experimenting is great. We should experiment.
>
> This doesn't mean we shouldn't discuss technical merits of the
> proposed solution, including more efficient ways of accomplishing the
> same thing.
>
> :DG<
>
> On Thu, Nov 26, 2009 at 9:44 AM, Dmitry Titov  wrote:
> > What I meant was it would be nice, for the sake of discussion, to share
> the
> > experience of real life applications that used SharedWorkers or
> inter-window
> > communications for sharing of significant portions of code and data.
> Google
> > apps may be a partial example but it is a real life example of concrete
> > issues with proposed solution that sounds pretty generic and useful for
> > other web apps. It is only prudent to take their feedback rather then
> > replace it with our own theories about future of the web. No doubt this
> is a
> > new mechanism and it's good to question it, since it has costs even as
> > experimental API. Gut feelings vary, some app devs say they need it to
> solve
> > real issues, we dont hear from other app devs who were facing similar
> issues
> > and solved it differently. Seems there is no strong argument to kill it
> nor
> > bless it. Why don't make it experimental and see? If it was possible to
> > implement it in extension or plugin, we would run it as another
> Gears-like
> > experiment, but it can not be done in a plugin... I believe there could
> be
> > good arguments that simply didn't surface yet, and hope to hear them.
> > Dmitry.
> >
> > On Wed, Nov 25, 2009 at 10:16 PM, Peter Kasting 
> wrote:
> >>
> >> On Wed, Nov 25, 2009 at 9:41 PM, Dmitry Titov 
> wrote:
> >>>
> >>> BTW, could you tell what's the 'course' that would be reverted?
> >>
> >> Meaning, "before we decide that SharedWorkers and inter-window
> >> communication are insufficient, and a further proposal should be
> entertained
> >> by the standards community".
> >> PK
> >
> > ___
> > 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] Runtime setting for incomplete features

[Michael Nordman]

window.applicationCache does something different when the runtime switch is
disabled which definitely breaks feature detection. It returns a non-null,
but non-functioning object. At some point I had changed it to return 'null'
when disabled, but  later reverted that change and went back to the non-null
but not-working state of affairs after discussing things with ap.
On Mon, Oct 5, 2009 at 7:50 PM, Drew Wilson  wrote:

> Ooops, meant to reply to all.
>
> On Mon, Oct 5, 2009 at 7:49 PM, Drew Wilson  wrote:
>
>>
>>
>> On Mon, Oct 5, 2009 at 6:40 PM, Sam Weinig  wrote:
>>
>>>
>>>
>>> That is not true, they are also available in nightly builds at
>>> http://nightly.webkit.org/.
>>>
>>
>> I'm not sure what you mean, exactly - the nightly webkit builds all have
>> SharedWorkers turned on, with no way to turn them off short of editing the
>> source code and recompiling (since the only existing implementation of
>> SharedWorkerRepository.isAvailable() returns true). I suspect I'm missing
>> something obvious, though - can you elaborate?
>>
>> My expectation was that only when I write the Chromium implementation of
>> SharedWorkerRepository will isAvailable() ever return false - so this only
>> affects Chromium deployments.
>>
>>
>>>
>>>


>
>> Regardless, I don't think we should rush out to roll all of those
>> features out of the tree, and I certainly don't think we should be 
>> singling
>> out SharedWorkers or WebSockets
>>
>
> I don't mean to single out SharedWorkers or WebSockets, but I don't see
> any others using the same technique (barring window.Audio, which I don't
> think is the same thing, but should non-the less be fixed).  But, as we 
> have
> many developers using the nightlies, I think this should be handled with
> some speed.
>

 Take a look at DOMWindow.cpp - there's quite a bit of code that does
 something like "look at settings to see if feature is enabled, return null
 if not" (DOMWindow::openDatabase(), for an example).


>>> This is indeed unfortunate, but also is a step removed, since it does not
>>> really effect feature detection, it is also not a shipping configuration.
>>>
>>
>> Why doesn't it affect feature detection? Someone can do "if localStorage
>> in window", yet have their code fail when window.localStorage is null?
>>
>>
>>>
>>> -Sam
>>>
>>
>>
>
> ___
> 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] FrameLoader cleanup

[Michael Nordman]

That is a much needed big job... look forward to seeing how the details
flesh out.

On Fri, Sep 25, 2009 at 2:01 PM, Adam Barth  wrote:

> On Fri, Sep 25, 2009 at 1:52 PM, Darin Adler  wrote:
> > On Sep 25, 2009, at 1:46 PM, Adam Barth wrote:
> >> 1) Separation of concerns. FrameLoader has its fingers in a bunch of
> >> different pies. In this phase, I'll try to break FrameLoader up into a
> bunch
> >> of smaller objects that are in charge of managing different pots of
> state.
> >
> > The whole plan sounds great. I’d like to hear more of the details of this
> > step.
>
> I haven't studied the code in enough detail yet to have many
> specifics, but here as some examples:
>
> A) Scheduled redirections.  There's a bunch of state associated with
> these that seems separable from the concerns of actually performing
> the loads.
>
> B) Methods involving PolicyAction.  Interacting with the
> FrameLoadClient seems like a separable issue from advancing the main
> state machine.
>
> C) Form submission.  There seem to be a bunch of special cases having
> to do with loading form submissions.  I haven't looked in detail, but
> this also seems like it should be a client of the core machine.
>
> As we get into the details, I'm sure we'll find some obvious wins.
>
> Adam
> ___
> 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] Loading from shared workers (shadow documents?)

[Michael Nordman]

Regarding "something special" for dedicated workers, the worker system will
have to initialize the ApplicationCacheHost associated with the shadow doc
specifically for a dedicated worker to know who the parent is (two integer
values, parent processID + cacheHostID). Beyond that, the appcache system
will be able to handle the differences (which should amount to very little).
We can look at that after the appcache related webkit API mods are landed
(which should happen this week).

On Sun, Aug 9, 2009 at 8:33 AM, Drew Wilson  wrote:

> That's a great point - we'll undoubtedly need to do something like this
> when we support appcache in shared workers.
> How hard would it be to setup a document like this? Dmitry, when you did
> something like this for Chromium, did you have to jump through many hoops
> when creating these documents? Since we use a shadow document for loading in
> Chromium already, do we have to do something special for dedicated workers
> so they inherit their parent's app cache?
> -atw
>
>
> On Sat, Aug 8, 2009 at 7:27 PM, Michael Nordman wrote:
>
>> On Fri, Aug 7, 2009 at 11:06 AM, Drew Wilson  wrote:
>>
>>> Hi all,
>>> I'm about to work on adding network access support to shared workers. To
>>> refresh your memory, shared workers can outlive any specific document object
>>> - they exit when the last referring document exits.
>>>
>>> Current dedicated workers just proxy all network operations over to their
>>> associated Document object. If the Document is closed prematurely, then the
>>> network operation is aborted and an error is returned to the worker, which
>>> is fine because the Worker is exiting anyway.
>>>
>>> For shared workers we can't just proxy network operations over to an
>>> arbitrary parent document, because the user may choose to close that
>>> document in mid-load yielding an inappropriate error response to the user.
>>> We have a few options:
>>>
>>> 1) If a document closes mid-load, just return an error to the worker. So
>>> treat this case like Just Another Network Hiccup.
>>>
>>
>>> 2) If a document closes mid-load, just retry the network access on
>>> another parent document. I'm not certain that this is acceptable from a
>>> spec-compliance standpoint (the server might end up seeing multiple network
>>> requests even though from the client stand point only one was issued).
>>>
>>> 3) Don't let documents fully go away while there's outstanding worker
>>> network access. For a long-lived hanging get, this seems like it might keep
>>> a document around (in hidden state) for a long time, and I'm not sure what
>>> the ramifications are of that. Also, there's the issue of how to deal with
>>> things like HTTP auth from hidden documents (although HTTP auth is
>>> problematic for shared workers in general as it's kind of arbitrary which
>>> window the auth UI appears under).
>>>
>>> 4) Create a new "shadow document" for the worker that it uses to satisfy
>>> all of its loading requests. This is what Chromium does for all its worker
>>> network access currently. This is the most robust solution, although I'm
>>> still not certain how HTTP auth would be handled in this case).
>>>
>>
>>  #4 seems like the most sensible option long term.
>>
>> * Solves the bug around spurious failures when the parent goes away at
>> just the wrong time.
>>
>> *  Avoids some appcache related complications. A shared worker can be
>> associated with an appcache that is all its own. It may be that none of the
>> parent documents are associated with the same appcache (or any appcache).
>> That situation seems like a recipe for awkward special cases in the loader
>> to delegate to the 'right' appcachehost when its processing a request on
>> behalf of a shared worker.
>>
>> Where to surface UI related to a shared worker's request is a good
>> question. Maybe a shared workers requests shouldn't present UI for HTTPauth
>> or SSL related prompts, anything that would require user intervention could
>> just fail w/o leaving any traces (we'd have to be careful to distinguish
>> these kind of failures from explicit user cancels when it came to the
>> validity state associated with the SSL cert).
>>
>>
>>> I'm leaning towards #1 in the short-term, but I'd like to get feedback
>>> about what our long-term approach should be.
>>>
>>> -atw
>>>
>>> ___
>>> 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] Calling All Reviewers

[Michael Nordman]

On Fri, Aug 7, 2009 at 3:37 PM, Joe Mason  wrote:

> Adam Treat wrote:
>
>> On Friday 07 August 2009 05:51:57 pm Eric Seidel wrote:
>>
>>> We also definitely need to fix our tools to make it impossible to post a
>>> patch w/o a ChangeLog, and impossible to post a patch that doesn't pass
>>> check-webkit-style.
>>>
>>
>> This is a bad idea.  check-webkit-style still has false positives and is
>> very new.  It has been designed to never be free of false positives in fact.
>>
>
> Not to mention there will always be places where human judgement overrides
> the guidelines.


Also, sometimes a patch is being posted not to be submitted, but to share
code to get early feedback on something. Requiring no style lint errors for
that use case seems overly restrictive.


>
> Joe
>
> ___
> 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] Loading from shared workers (shadow documents?)

[Michael Nordman]

On Fri, Aug 7, 2009 at 11:06 AM, Drew Wilson  wrote:

> Hi all,
> I'm about to work on adding network access support to shared workers. To
> refresh your memory, shared workers can outlive any specific document object
> - they exit when the last referring document exits.
>
> Current dedicated workers just proxy all network operations over to their
> associated Document object. If the Document is closed prematurely, then the
> network operation is aborted and an error is returned to the worker, which
> is fine because the Worker is exiting anyway.
>
> For shared workers we can't just proxy network operations over to an
> arbitrary parent document, because the user may choose to close that
> document in mid-load yielding an inappropriate error response to the user.
> We have a few options:
>
> 1) If a document closes mid-load, just return an error to the worker. So
> treat this case like Just Another Network Hiccup.
>

> 2) If a document closes mid-load, just retry the network access on another
> parent document. I'm not certain that this is acceptable from a
> spec-compliance standpoint (the server might end up seeing multiple network
> requests even though from the client stand point only one was issued).
>
> 3) Don't let documents fully go away while there's outstanding worker
> network access. For a long-lived hanging get, this seems like it might keep
> a document around (in hidden state) for a long time, and I'm not sure what
> the ramifications are of that. Also, there's the issue of how to deal with
> things like HTTP auth from hidden documents (although HTTP auth is
> problematic for shared workers in general as it's kind of arbitrary which
> window the auth UI appears under).
>
> 4) Create a new "shadow document" for the worker that it uses to satisfy
> all of its loading requests. This is what Chromium does for all its worker
> network access currently. This is the most robust solution, although I'm
> still not certain how HTTP auth would be handled in this case).
>

 #4 seems like the most sensible option long term.

* Solves the bug around spurious failures when the parent goes away at just
the wrong time.

*  Avoids some appcache related complications. A shared worker can be
associated with an appcache that is all its own. It may be that none of the
parent documents are associated with the same appcache (or any appcache).
That situation seems like a recipe for awkward special cases in the loader
to delegate to the 'right' appcachehost when its processing a request on
behalf of a shared worker.

Where to surface UI related to a shared worker's request is a good question.
Maybe a shared workers requests shouldn't present UI for HTTPauth or SSL
related prompts, anything that would require user intervention could just
fail w/o leaving any traces (we'd have to be careful to distinguish these
kind of failures from explicit user cancels when it came to the validity
state associated with the SSL cert).


> I'm leaning towards #1 in the short-term, but I'd like to get feedback
> about what our long-term approach should be.
>
> -atw
>
> ___
> 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] Reporting exceptions from worker context to users

[Michael Nordman]

> Nor do I think that we should block development on arbitrary features like 
> nested workers
> because we think we need better tools. A better solution would be to roll out 
> a "just barely good
> enough" solution, get developer feedback on real use cases, and improve the 
> tools over time to
> reflect that feedback, just as we do for every other feature in WebKit.

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

Re: [webkit-dev] Reporting exceptions from worker context to users

[Michael Nordman]

> it sounds like we have one vote for "just log them to the console for every 
> connected document"

sgtm


On Sat, Aug 1, 2009 at 12:39 PM, Drew Wilson wrote:
> Yes, SharedWorkers will eventually be able to communicate with one another,
> as will DedicatedWorkers. So at some point we'll have a big connected graph
> of workers that potentially might be interesting for people to traverse and
> inspect their global contexts (I'm not sure - I don't think we know yet what
> debugging tools will be useful for developers).
> Further agreed, the HTML5 spec states that exceptions from shared workers
> are *not* propagated to parent pages for application execution - this would
> be solely for logging purposes.
> In the meantime while we work towards our glorious future, I'd still like to
> log exceptions somewhere :) It sounds like we have one vote for "just log
> them to the console for every connected document".
>
> -atw
>
> On Sat, Aug 1, 2009 at 10:35 AM, Michael Nordman 
> wrote:
>>
>> Shared workers can also communicate directly with one another, is that
>> right? And its possible to have a shared worker whose only client is
>> another shared worker, is that right?
>>
>> Feels like we should be working towards inspecting shared workers
>> directly. Where a page inspector would show which shared workers it
>> was connected to, and you could open a separate inspector to see what
>> is going on within each shared worker (including which shared workers
>> it was connected to).
>>
>> Broadcasting exceptions within a worker to its clients for inspection
>> purposes may be useful even with separate inspectors per shared
>> worker. The client's 'shared worker' tab  (or console) could log
>> unhandled exceptions occurring in each, as you described, encouraging
>> the developer to look into it... open the shared worker inspector and
>> poke around.
>>
>> About broadcasting unhandled shared worker exceptions in general...
>>
>> It makes sense to have unhandled exceptions in a dedicated process
>> propagated to the parent page's context (which may presumably handle
>> the exception in some way). But I'm not sure that model applies to
>> unhandled exceptions in shared workers. The possibility of multiple
>> connected pages, which should "handle it"? Seems good for
>> logging/debugging purposes to have them show up in the client's
>> inspector, but doesn't sound like a good fit for application execution
>> purposes.
>>
>>
>> On Sat, Aug 1, 2009 at 9:31 AM, Drew Wilson wrote:
>> > Hi all,
>> > Currently, unhandled exceptions are sent from worker context over to the
>> > parent page where they are logged to the console. This works fine for
>> > dedicated workers, but not for shared workers which can have multiple
>> > active
>> > windows.
>> > The immediate solution that springs to mind is to broadcast the
>> > exception to
>> > every window associated with a shared worker, and have each window log
>> > the
>> > unhandled exception to its console. Is there another option that might
>> > be
>> > better (is there the concept of an inspector/console that is not
>> > associated
>> > with a specific window, for example)?
>> > -atw
>> > ___
>> > 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] Reporting exceptions from worker context to users

[Michael Nordman]

Shared workers can also communicate directly with one another, is that
right? And its possible to have a shared worker whose only client is
another shared worker, is that right?

Feels like we should be working towards inspecting shared workers
directly. Where a page inspector would show which shared workers it
was connected to, and you could open a separate inspector to see what
is going on within each shared worker (including which shared workers
it was connected to).

Broadcasting exceptions within a worker to its clients for inspection
purposes may be useful even with separate inspectors per shared
worker. The client's 'shared worker' tab  (or console) could log
unhandled exceptions occurring in each, as you described, encouraging
the developer to look into it... open the shared worker inspector and
poke around.

About broadcasting unhandled shared worker exceptions in general...

It makes sense to have unhandled exceptions in a dedicated process
propagated to the parent page's context (which may presumably handle
the exception in some way). But I'm not sure that model applies to
unhandled exceptions in shared workers. The possibility of multiple
connected pages, which should "handle it"? Seems good for
logging/debugging purposes to have them show up in the client's
inspector, but doesn't sound like a good fit for application execution
purposes.


On Sat, Aug 1, 2009 at 9:31 AM, Drew Wilson wrote:
> Hi all,
> Currently, unhandled exceptions are sent from worker context over to the
> parent page where they are logged to the console. This works fine for
> dedicated workers, but not for shared workers which can have multiple active
> windows.
> The immediate solution that springs to mind is to broadcast the exception to
> every window associated with a shared worker, and have each window log the
> unhandled exception to its console. Is there another option that might be
> better (is there the concept of an inspector/console that is not associated
> with a specific window, for example)?
> -atw
> ___
> 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

[Michael Nordman]

> Having a dedicated shadow frame would be much simpler.
Yup.

I think this is required ultimately for appcache integration too. A shared
worker is a distinct appcache host. Dedicated workers can get away with
piggy backing of their owning document since they just use the same appcache
as the page, but not shared workers.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[Michael Nordman]

On Wed, Jun 17, 2009 at 3:43 PM, Drew Wilson  wrote:

> Following up again on this - now that my cross-thread MessagePort patch is
> getting close to landing, I am moving forward on the SharedWorker design
> described earlier in this thread.
> I think there is still little clarity around the appcache behavior (dimich:
> are you bring over your "shadow frame" concept to webkit?).
>

I think we're making decent progress, but integration with workers is a ways
off yet. First things first for me, get things working w/o workers.

I'm wondering about bringing the 'shadow frame' technique to webcore too?


>
> It doesn't seem like it should block the rest of SharedWorker development
> while we work out the details - I will not expose the appcache APIs for
> SharedWorkers until we have consensus about how they should work.
>

Sounds good. You should plow ahead without concern for appcache integration.
I'll back fill later. We'll have similar backfilling to do with the Database
too.


>
>
> Let me know if you have any concerns with my approach. I'll add an
> ENABLE_SHARED_WORKERS flag to control access to these APIs while development
> proceeds.
>
> -atw
>
>
> On Tue, Jun 2, 2009 at 11:43 AM, Michael Nordman wrote:
>
>> > As for our implementation - I don't know how appcache is integrated with
>> the
>> > loader code.
>>
>> We're still working out the details sans workers. But if it's a
>> requirement to be able to a have an distinct "appache host" per shared
>> worker, then so be it.
>>
>> > If not, we either need to add this support, or delay exposing appcache
>> APIs to SharedWorkers
>> > until we add the ability to load data from worker context without going
>> through a document
>> > object (probably required for persistent workers).
>>
>> I'm for deferring appcache + worker integration until we have appcach
>> - worker integration in place (including in place for chrome).
>>
>> Exposing the scriptable APIs to workers don't necessarily have to go
>> in lock step with and appcache selection and resource loading on
>> behalf of workers.
>>
>> There may be some overlap with work being done to support resource
>> loading for dedicated workers in chrome. In chrome resource loads
>> don't go thru the renderer process at all (so no Document/Frame
>> instances). I think Dmitry was talking about introducing a "FakeFrame"
>> (maybe not the best name) for this purpose.
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[Michael Nordman]

> As for our implementation - I don't know how appcache is integrated with the
> loader code.

We're still working out the details sans workers. But if it's a
requirement to be able to a have an distinct "appache host" per shared
worker, then so be it.

> If not, we either need to add this support, or delay exposing appcache APIs 
> to SharedWorkers
> until we add the ability to load data from worker context without going 
> through a document
> object (probably required for persistent workers).

I'm for deferring appcache + worker integration until we have appcach
- worker integration in place (including in place for chrome).

Exposing the scriptable APIs to workers don't necessarily have to go
in lock step with and appcache selection and resource loading on
behalf of workers.

There may be some overlap with work being done to support resource
loading for dedicated workers in chrome. In chrome resource loads
don't go thru the renderer process at all (so no Document/Frame
instances). I think Dmitry was talking about introducing a "FakeFrame"
(maybe not the best name) for this purpose.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[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 :
>
> Basically, the spec says "the most appropriate app cache should be used"
> (which apparently we're free to interpret however we like), and that the
> SharedWorker should have the ability to update its current app cache. I
> think that the spec is fine.
> As for our implementation - I don't know how appcache is integrated with the
> loader code. Can I proxy a load to a given document, but still specify which
> version of the app cache I want to use? If so, then we don't need to change
> the
> design. If not, we either need to add this support, or delay exposing appcache APIs to SharedWorkers until we add the ability to load data from worker context without going through a document object (probably required for persistent workers).
> -atw
>
> 2009/6/2 Alexey Proskuryakov 
>>
>> 02.06.2009, в 21:59, Michael Nordman написал(а):
>>
>>> Per the spec, shared workers are a distinct "browsing context". In
>>> appcache terms, they have a distinct "appcache host". We have to come
>>> up with a design that accomplishes that.
>>
>>
>> OK, I was getting a feeling that we talked about different things. Andrew,
>> do you agree that a different design is needed, or is this something we
>> should push into the spec instead?
>>
>> - WBR, Alexey Proskuryakov
>>
>>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[Michael Nordman]

2009/6/2 Alexey Proskuryakov :
>
> From Andrew's design document, I don't see how my description was
> inaccurate:
>
> ---
> Currently, all worker XHR requests are proxied to the parent page and
> executed on the main thread. This approach currently works for dedicated
> workers because there is a 1:1 mapping between dedicated workers and active
> pages, and the worker is shutdown when the page closes. For SharedWorkers
> (and for dedicated workers once we introduce nested workers) this is no
> longer the case - the worker can outlive the parent page.
>
> To address this, we will use the DocumentSet for the worker. Worker XHR
> requests will still be proxied to the main thread. This task will request
> the DocumentSet from the repository, and select a document from that set to
> use to satisfy the request. If the DocumentSet is empty, then it means that
> the worker is shutting down, so the XHR should return a failure response.
> ---
>
> From my reading of this, it appears that shared workers will use FrameLoader
> of the opener page, or some other page in the DocumentSet, and won't get
> their own loaders (that would be a feature of persistent workers, which we
> aren't even discussing yet). This speaks specifically about XHR, but I
> assumed that the same holds true for other network requests.

That would be a design flaw... not a feature. All of this stuff about
the DocumentSet associated with a shared worker is a hack to work
around the problem of "how to load resource without a frame in
webkit".

Per the spec, shared workers are a distinct "browsing context". In
appcache terms, they have a distinct "appcache host". We have to come
up with a design that accomplishes that.



>
> - WBR, Alexey Proskuryakov
>
>
> 02.06.2009, в 21:18, Michael Nordman написал(а):
>
>>> When a document calls a SharedWorker constructor, the worker script is
>>> loaded from the document's
>>> appcache (because all subresource loading goes through appcache, of
>>> course).
>>
>> If I understand correctly, that is not what the spec currently says.
>>
>> Dedicated workers load as you describe, but not shared workers. The
>> algorithm to determine what resource to load for a shared worker is
>> the same as the algorithm used to determine what resource to load for
>> a window.open(urlToPageWithoutAManifestAttributre) call.
>>
>> Personally, I think we should defer adding support for the appcache
>> scriptable API to workers for the time being. But do support the
>> resource loading / cache selection as currently specified. This would
>> allow shared workers can be versioned independently (despite not
>> having a good reload worker after an update story).
>>
>> These are shared workers. That implies a degree of separation from the
>> pages that are sharing them.
>
>
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[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 :
>
> 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

[Michael Nordman]

How workers and appcaches interact has been discussed on the WHATWG
list. Ian's "Worker feedback" message on 3/27/09 tried to tie things
up for the time being. I think where he left things was a reasonable
stepping stone, although the answers to the questions being asked here
about updates were not entirely resolved.

> What is the use case for this? It doesn't seem useful to me - to invoke 
> update explicitly, one
> normally needs to have UI anyway, at which point it's much easier to call 
> update() directly from a
> page.

The use case are workers that can be considered "faceless
applications". They are versioned independently of user interfaces
that make use of them thru a stable message based API.

> A tangentially related question: what will happen to a SharedWorker whose 
> cache got updated?
> Will the repository use a new source for new instances, while the old ones 
> will continue to run?

I think the intent of the current spec is that a new instance would
not be created provided there is an existing instance already running.
How to reload an existing worker to utilize new resources in an
updated cache was left as an exercise to the reader.

At least that's my understanding of the current spec.


2009/6/1 Drew Wilson :
>
>
> 2009/6/1 Alexey Proskuryakov 
>>
>> 01.06.2009, в 22:37, Drew Wilson написал(а):
>>
>> 1) Since SharedWorkers aren't explicitly tied to a specific Document, it
>> doesn't make sense to have them possibly get loaded from an out-of-date
>> version of the app cache. If you have two separate documents running from
>> different caches, it's weird (and indeterminate) if the version of the cache
>> used to load the SharedWorker script is dependent on which one happens to
>> call "new SharedWorker()" first.
>>
>> I don't see how exposing DOMApplicationCache methods to workers can help
>> this  - a worker will only be able to call DOMApplicationCache.update()
>> after it has started, which is too late.
>
> Not sure why that is "too late"? Can you clarify?
>
>>
>> Besides, won't the document using an old version of cache break if a newer
>> SharedWorker is suddenly returned to it? The main idea of appcache is that
>> all application resources are versioned, so if we see SharedWorkers as part
>> of application, they should use the same cache version. And if they are
>> independent entities with a stable API, using an out of date version for a
>> while cannot hurt.
>
> Why would a document using an old version of cache break if a newer
> SharedWorker is returned? Why is that any more of a problem than a document
> using a new version of cache breaking if an older SharedWorker is returned,
> which is what would happen if SharedWorkers inherited appcache from the
> first document that instantiated them?
> It seems like there are several easy options available to apps:
> 1) Change the name of the shared worker if a non-backward-compatible change
> needs to be made to the worker script (so new documents don't share the same
> worker instance as old documents)
> 2) When updates are available, coordinate updates with all documents so
> everyone updates at once, possibly exiting the SharedWorker.
>
>>
>> As for what happens to a SharedWorker whose cache was updated? My
>> presumption is that all future resource loads would use that cache. At that
>> point, the SharedWorker has a few different things it could do:
>>
>> Reload all of its scripts again using importScripts(). This implies that
>> its script loading is idempotent, but that's not too hard to do.
>> Send messages to all of its client documents letting it know that it is
>> shutting down, then invoke close() to shut itself down. The client documents
>> can re-create the SharedWorker the next time they want one. This is
>> inherently race-y, though, since you can't easily coordinate the shutdown of
>> the worker with instantiations of new ones.
>> Do nothing at all
>>
>> All of these options seem quite dangerous - it may be difficult for JS
>> authors to write applications that won't break at update time.
>
> It might be tricky, although any application that does dynamic JS loading
> has to deal with versioning issues already. This is not particularly
> different.
>
>>
>>
>>
>> A document can reload itself after updating, but SharedWorkers do not have
>> a way to reload themselves. As you mentioned, they can reload imported
>> scripts (but the main script will remain the same, which would be
>> inconsistent).
>
> Why can't they reload the main script? Again, there's a need to be
> idempotent if you need to maintain some cached state, but it's not totally
> impossible.
>
>>
>> Or they can shut down and ask a document to re-create themselves - at
>> which point, we can as well say that the document can update the cache.
>
> I'm not arguing against this, I just don't see how it works when you have
> multiple documents each of which are running from different versions of the
> app cache, where the shared worker itself is attached to some 

Re: [webkit-dev] AppCache class naming (WAS Re: SharedWorkers alternate design)

[Michael Nordman]

>  one might reasonably assume that in Chrome, the renderer process is the back 
> end

Not really. We do use the terms front and back, but they usually refer
to something a bit orthognal to this child/main process distinction...
closer to network stack vs closer to browserui is generally what these
terms refer to.

Anyway... how these terms are used in chromium shouldn't influence our
use of these terms in webcore much... in webcore-land we (me at least)
were thinking 'front' == closer to script and html content, 'back' ==
farther away from that.

> I can make suggestions in the context of reviewing a patch if you guys don't
> want to discuss it any more. I'm not clear enough on how exactly you split
> the classes to make a good suggestion.

That would be great. Here's a patch...
https://bugs.webkit.org/show_bug.cgi?id=25436
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] AppCache class naming (WAS Re: SharedWorkers alternate design)

[Michael Nordman]

Frontend/Backend was my first choice too... based on how we ended up
discussing the split of things, seemed natural... maciej wasn't too
keen on that thou...

@Maciej, any strong objections or opinions?


On Fri, May 29, 2009 at 12:04 PM, Jeremy Orlow wrote:
> HaKitchen/Counter were an attempt to push thinking in the right
> direction, not a real suggestion.
>
> Agree that this is a rat hole and it we need to move on.
>
> Still think Frontend/Backend is the clearest thing despite being used in a
> different manner in some other places and despite Client/Server(/Service)
> being used elsewhere.  But Client/Service is my second choice.
>
> J
>
> On Fri, May 29, 2009 at 11:57 AM, Michael Nordman 
> wrote:
>>
>> I really have no strong opinions one way or the other (or the other),
>> so long as its somewhat intelligible I'm good.
>>
>> Having said that
>> Kitchen and Counter don't pass muster for me :)
>> Bindings mean script bindings... not gonna overload that for this
>>
>> Intelligible options any of which work for me so far
>> * FooFacade FooSystem
>> * FooFrontend FooBackend
>> * FooClient FooService
>>
>> We should wrap this rat hole up.
>>
>>
>> On Fri, May 29, 2009 at 11:16 AM, Jeremy Orlow wrote:
>> > On Thu, May 28, 2009 at 4:32 PM, Michael Nordman 
>> > wrote:
>> >>
>> >> > Can you think of a more specific way to describe the reationship than
>> >> > "front" and "back" or "client" and "service"? Does one of the Gang of
>> >> > Four
>> >> > Design Patterns apply? That can be a good resource for clear ways to
>> >> > describe class relationships, even fairly abstract ones.
>> >>
>> >> Nice suggestion...
>> >>
>> >> In my case Facade may be the most appropriate name for what i've been
>> >> referring to as the 'frontend' interface. I'm endeavoring to provide a
>> >> simplified interface (a facade) to a more complex system, the moving
>> >> parts of which are not important to clients of the facade.
>> >>
>> >> Inside that Facade, Proxy may be the most appropriate for the
>> >> messaging abstraction parts.
>> >>
>> >> ApplicationCacheFacade
>> >>   * uses ApplicationCacheSystemProxy
>> >>
>> >> ApplicationCacheSystem
>> >>  * uses ApplicationCacheFacadeProxy
>> >>
>> >> WDYT?
>> >
>> > I'm not really sure this is a Facade pattern.  I think a good example of
>> > the
>> > facade pattern is the WebKit to WebCore relationship: a complex inner
>> > system
>> > that's made to be easy to use via the facade.
>> >
>> > Personally, I find the names less clear than Client/Server (or
>> > Backend/Frontend).
>> >
>> > What if we could come up with some more clear synonyms for
>> > Backend/Frontend?  Another way to think about it is that the frontend is
>> > the
>> > seating area (or counter) of a resteraunt and the backend is the
>> > kitchen.
>> > What other metaphores along these lines would be similar?  Maybe
>> > something
>> > about Storage vs Bindings (since the one half is about storing
>> > everything
>> > and the other is about hooking it into the resource loading)?  I don't
>> > knowjust trying to brainstorm here.
>> >
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] AppCache class naming (WAS Re: SharedWorkers alternate design)

[Michael Nordman]

I really have no strong opinions one way or the other (or the other),
so long as its somewhat intelligible I'm good.

Having said that
Kitchen and Counter don't pass muster for me :)
Bindings mean script bindings... not gonna overload that for this

Intelligible options any of which work for me so far
* FooFacade FooSystem
* FooFrontend FooBackend
* FooClient FooService

We should wrap this rat hole up.


On Fri, May 29, 2009 at 11:16 AM, Jeremy Orlow wrote:
> On Thu, May 28, 2009 at 4:32 PM, Michael Nordman 
> wrote:
>>
>> > Can you think of a more specific way to describe the reationship than
>> > "front" and "back" or "client" and "service"? Does one of the Gang of
>> > Four
>> > Design Patterns apply? That can be a good resource for clear ways to
>> > describe class relationships, even fairly abstract ones.
>>
>> Nice suggestion...
>>
>> In my case Facade may be the most appropriate name for what i've been
>> referring to as the 'frontend' interface. I'm endeavoring to provide a
>> simplified interface (a facade) to a more complex system, the moving
>> parts of which are not important to clients of the facade.
>>
>> Inside that Facade, Proxy may be the most appropriate for the
>> messaging abstraction parts.
>>
>> ApplicationCacheFacade
>>   * uses ApplicationCacheSystemProxy
>>
>> ApplicationCacheSystem
>>  * uses ApplicationCacheFacadeProxy
>>
>> WDYT?
>
> I'm not really sure this is a Facade pattern.  I think a good example of the
> facade pattern is the WebKit to WebCore relationship: a complex inner system
> that's made to be easy to use via the facade.
>
> Personally, I find the names less clear than Client/Server (or
> Backend/Frontend).
>
> What if we could come up with some more clear synonyms for
> Backend/Frontend?  Another way to think about it is that the frontend is the
> seating area (or counter) of a resteraunt and the backend is the kitchen.
> What other metaphores along these lines would be similar?  Maybe something
> about Storage vs Bindings (since the one half is about storing everything
> and the other is about hooking it into the resource loading)?  I don't
> knowjust trying to brainstorm here.
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[Michael Nordman]

> Can you think of a more specific way to describe the reationship than
> "front" and "back" or "client" and "service"? Does one of the Gang of Four
> Design Patterns apply? That can be a good resource for clear ways to
> describe class relationships, even fairly abstract ones.

Nice suggestion...

In my case Facade may be the most appropriate name for what i've been
referring to as the 'frontend' interface. I'm endeavoring to provide a
simplified interface (a facade) to a more complex system, the moving
parts of which are not important to clients of the facade.

Inside that Facade, Proxy may be the most appropriate for the
messaging abstraction parts.

ApplicationCacheFacade
   * uses ApplicationCacheSystemProxy

ApplicationCacheSystem
  * uses ApplicationCacheFacadeProxy

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

Re: [webkit-dev] SharedWorkers alternate design

[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

[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] Notifications API

[Michael Nordman]

> but that seems inherent to the general model of the web

Agreed, I'm suggesting that model can be improved upon.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Notifications API

[Michael Nordman]

Its a comfortable notion that an origin == application, but the
reality is that a single site can host multiple applications, and that
an individual application can span multiple origins.

We can probably do better than imposing the origin == application
model on everybody.

The only organizing principles we have for web permission granting are
at the page level or at the origin level. Neither of these is
particularly satisfying.

I think end users would like to see things in terms of "applications".
The web provides no means of identifying which pages/origins should be
considered part of an application. If there was a sense of
"application'ness", we could apply permissions to them... which is a
desirable goal i think.

So how to establish a sense of application'ness?


If a page that doesn't identify itself start requesting permissions...
fallback on the origin = application model.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[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

[Michael Nordman]

I think we're on the same page. What you described sounds good to me.

I think ResourceHandle case is different because its involved in more
than appcache specific stuff. In chrome the calls into the appcache
while resource loading would occur on the chrome-side of the wire from
chrome specific code (not from webcore). In the single-process model,
the calls into the appcache would occur from webcore code.


On Tue, May 26, 2009 at 6:11 PM, Jeremy Orlow wrote:
> On Tue, May 26, 2009 at 6:02 PM, Michael Nordman 
> wrote:
>>
>> > To clarify, I'm saying that your question made me realize that we
>> > probably
>> > can make a hard split between the frontend and backend code (i.e. what
>> > would
>> > live in a sandbox and handle page rendering and what wouldn't live in a
>> > sand
>> > box and store the actual DOM Storage data).  In single process cases
>> > where
>> > there is no IPC barrier, and thus no proxy (and thus the actual
>> > implementation code should be called directly) a typedef should bridge
>> > the 2
>> > with no run time performance penalty.
>> >
>> > Darin, Sam, Maciej: does this alleviate your concerns?
>> >
>> > Michael, Drew, John: do you think it'd work for workers/appcache as
>> > well?
>>
>> Partly.
>>
>> The split you just described is what I have in mind for the scripting
>> related appcache interfaces. There always exists a hard split between
>> front and back. The nature of the proxy is different depending. Btw, I
>> also have in mind to use webcore's backend appache code in the
>> seperate process (chrome's main process).
>>
>> The appcache is complicated by the fact that in addition to the
>> scripting related interfaces, there are also interfaces around loading
>> resources out of the cache. The loader currently calls into the
>> appcache and wants an answer immediately (syncrhronously). These call
>> happen at times not so friendly to remoting, like in advance of
>> checking the memory cache... so I don't like the idea of injecting
>> sync IPC calls at those times. I'm still wrestling with that part. I
>> have in mind to overload ResourceHandle such that it knows how to load
>> out of the appropiate appcache when needed, but what I haven't worked
>> thru are how this plays well with webcore's memory cache.
>
> Did you say partly because it's more complicated than just splitting one
> class (and only having 1-way sync communication)?  If so, then we're still
> on the same page, because that's what I'll be doing as well.  I was just
> using the StorageBackend as an example, but events will require signals from
> the backend to the frontend, and some abstractions (like StorageArea) make a
> lot of sense whether or not things are split into two pieces, which sounds a
> lot like what you described with ResourceHandle.
>
> If not, what cases are there where you can't cleanly split things into the 2
> buckets: "call the proxy if it exists, otherwise call the implementation"
> and "ALWAYS call the implementation"
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] SharedWorkers alternate design

[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

[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

[webkit-dev] AppCache resource loading in a multi-process world

[Michael Nordman]

Hi all,

Please refer to https://bugs.webkit.org/show_bug.cgi?id=25436.

Alexey and I have been trading messages in that issue. He suggested
that I bring this up aspects of that issue on the larger list.
> I think that the best way forward is to discuss general multi-process loader
> architecture on the mailing list, with appcache design being a natural part of
> it.

The issue is how to accommodate loading out of an appcache in a
multi-process browser. I've been working towards a solution where the
main process is the only process with direct access to the appcache
data on disk. Please see the bug for details.

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

Re: [webkit-dev] setting a size limit for Application Cache

[Michael Nordman]

On Wed, May 6, 2009 at 12:45 PM, Jeremy Orlow  wrote:
> Good point.  Tying the apps together is pretty important.  What good is it
> for the program to still be in AppCache if it's data (in databases or
> localStorage) was deleted by some other LRU policy?
> I'm not sure that yet another manifest is needed though.  For databases and
> localStorage, access is controlled via the origin.  It seems to me that the
> minimum granularity for what gets pinned is thus the domain.

Assuming app == domain has proven problematic. Not only are there
multiple apps per domain, there are apps that span multiple domains.

> Yes, there can be multiple web applications per domain, but there's really
> no way for WebKit to know which localStorage entries or which databases are
> tied to each application.  Thus, eviction is an all or nothing thing for the
> origin.  This is not such a horrible thing though; authors can always create
> sub-domains for each web application.

"sub-domains for each web application" has proven to be easier said than done

> So, in summary: I'm proposing that there be a UI to pin (or install, or
> save, or whatever you want to call it) an origin + have a dialog for seeing
> all the origins that are pined (for uninstall purposes).  All non-pinned
> AppCache data would be removed in a LRU fashion.

Some thing the system needs is a 'trigger' to bring up such a UI. The
presence of a  attribute, in which the
descriptor file expresses it desire for the 'persistance' privilege,
could provide such a trigger.


> On Wed, May 6, 2009 at 12:09 PM, Michael Nordman 
> wrote:
>>
>> The chrome team had an interesting thread on this topic not long ago.
>> Unfortunately it wasn't on the public chromium-dev mailing list, so I
>> can't provide a link to it here :(
>>
>> 
>>
>> The gist of it was that providing appcaching for general use w/o any
>> special privileges is a good thing, but not all usages of this feature
>> are qualitatively the same thing. In some cases it's purely about
>> performance enhancement or reduced network utilization (traditional
>> caching goals). In other cases it's about providing additional
>> guarantees around application availability. Its fair to evict data
>> cached for the former cases as needed, but not ok to evict data cached
>> for the latter cases.
>>
>> There is no means for the system to distinguish between these two
>> cases. There is no API to indicate which use is which.
>>
>> In the latter case (gauranteed app availability), there is more
>> involved than the appcache... there are also databases, localstorage
>> values to which the gaurantee extends to.
>>
>> What's missing is a way for "applications" to declare themselves as
>> such and to establish privileges to keep data around forever. Given
>> that, the system could relate persistent resource with "applications",
>> and based on their privileges, evict or not when space becomes an
>> issue.
>>
>> A handwavvy syntax for declaring an "application"... > application='someurl'>... the url uniquely identifies the app, the
>> resource loaded from that url contains a user friendly description and
>> set of desired privileges... all pages that refer to that application
>> url are considered part of that app... all resource created on behalf
>> of that app are tracked by the system as such.
>>
>> Food for thought.
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] setting a size limit for Application Cache

[Michael Nordman]

The chrome team had an interesting thread on this topic not long ago.
Unfortunately it wasn't on the public chromium-dev mailing list, so I
can't provide a link to it here :(



The gist of it was that providing appcaching for general use w/o any
special privileges is a good thing, but not all usages of this feature
are qualitatively the same thing. In some cases it's purely about
performance enhancement or reduced network utilization (traditional
caching goals). In other cases it's about providing additional
guarantees around application availability. Its fair to evict data
cached for the former cases as needed, but not ok to evict data cached
for the latter cases.

There is no means for the system to distinguish between these two
cases. There is no API to indicate which use is which.

In the latter case (gauranteed app availability), there is more
involved than the appcache... there are also databases, localstorage
values to which the gaurantee extends to.

What's missing is a way for "applications" to declare themselves as
such and to establish privileges to keep data around forever. Given
that, the system could relate persistent resource with "applications",
and based on their privileges, evict or not when space becomes an
issue.

A handwavvy syntax for declaring an "application"... ... the url uniquely identifies the app, the
resource loaded from that url contains a user friendly description and
set of desired privileges... all pages that refer to that application
url are considered part of that app... all resource created on behalf
of that app are tracked by the system as such.

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

Re: [webkit-dev] AppCache functionality provided by the embedder of webkit

[Michael Nordman]

On Tue, Apr 7, 2009 at 11:27 AM, Maciej Stachowiak  wrote:

>
> On Apr 7, 2009, at 10:52 AM, Michael Nordman wrote:
>
>  I'm working on the app cache for Chrome. We've decided to hoist most the
>> functionality provided by the app cache into Chrome's main browser process,
>> so we won't be using most of the implementation provided by WebKit. I'd like
>> to work through what changes to make within WebKit/WebCore to allow an
>> embedder pull that off. Any suggestions would be much appreciated.
>>
>
> One downside of this approach is that, if the application cache ever needs
> to change, it may be necessary to make changes to two separate
> implementations hosted in different repositories. In addition,
> quality-of-implementation improvements to one version won't benefit the
> other.


Please see my response to Darin earlier. There may be an opportunity to
replace WebKit's impl of this feature with one that has more manageable
dependencies. Perhaps chrome's implementation could be the basis for that
replacement which could then be used within webkiit proper and within
chrome's browser process.

A first step along this path could be enabling somebody to wire in a
different implementation that is lagging the current incarnation found in
webkit at the moment and not ready for the prime time just yet.

Some additional info about Chrome's as yet non-existent impl. It needs to be
fairly independent of the core chrome codebase in order for it to be
testable in our current testing infrastructure for the layout tests. This is
a design constraint which will keep me honest regarding dependencies.


>
> It's been a recurring theme for the Chrome team to request hooks to bypass
> WebKit functionality and replace it with Chrome-specific code that lives
> outside the WebKit tree. So far this has been mostly for code developed when
> Chrome was originally a secret project. While we felt it was best to
> grandfather in the existing carve-outs, in general I believe this is not the
> best way to move the WebKit project forward. I would not like to see this
> pattern replicated for newly developed functionality.


WebKit could grow a stronger sense of frontend vs backend that don't share
an address space for features that require touching browser wide state. The
current model for webkit doesn't lend itself well for that. We struggle with
that a fair amount.


>
> Regards,
> Maciej
>
>
>> In the code base right now, a single compilation flag enables or disables
>> everything to do with app cache in WebKit, ENABLE(OFFLINE_APPLICATION). This
>> turns on/off the scriptable interface bits as well as the backend
>> implementation within webcore. I think I'd like a way to reuse the
>> scriptable interface related bits provided by webkit, but to slide a chrome
>> specific implementation under that interface. One thought was to separate
>> this single flag into two flags, one for the scriptable interface bits and
>> the other for the back end implementation.
>>
>> ENABLE(APPLICATION_CACHE_INTERFACE)
>> - surfaces the window.applicationCache property
>> - pulls in the DOMApplicationCache.idl file
>> - enables event targeting stuff for DOMApplicationCache
>> - perhaps defines an abstract interface that a c++ class backing
>> DOMApplicationCache scriptable API must implement
>>
>> ENABLE(APPLICATION_CACHE_IMPLEMENTATION)  // only valid if INTERFACE is
>> also enabled
>> - turns on the rest of the stuff in webkit for app cache, including a
>> concrete implementation of that abstract interface mentioned above.
>>
>> Does something along these lines make sense, or perhaps there is another
>> way to approach this?
>>
>> Thnx
>> Michael
>>
>>
>>
>>
>>
>> ___
>> 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] AppCache functionality provided by the embedder of webkit

[Michael Nordman]

Good question.
In general, we've avoided using WebKit code in what we call the browser
process (that's the main process in chrome). I'm not sure how firm that
policy is. If we were to utilize significant amounts of webcore code in the
browser process, we'd have an interesting conundrum about which thread we'd
have webkit consider its "main" thread. For appcache purposes, this would
ideally be some background thread, for other purposes this would ideally be
what we call the UI thread in the browser process.

Ultimately, I think an arrangement that you're alluding to would be the best
answer. A common implementation of the AppCache with clean dependencies and
interfaces such that it can be re-used in different environments.

I was not gunning to take that on as part of my project in the near term as
I think that would be disruptive to Chrome and WebKit alike. But down that
road, this is an intriguing idea.

On Tue, Apr 7, 2009 at 11:16 AM, Darin Adler  wrote:

> On Apr 7, 2009, at 10:52 AM, Michael Nordman wrote:
>
>  We've decided to hoist most the functionality provided by the app cache
>> into Chrome's main browser process,
>>
>
> Perhaps other WebKit ports will want a similar structure. Is there a way
> this code in the main browser process could still be WebKit code, or does it
> have special requirements that make it need to be Chrome-specific?
>
>-- Darin
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] AppCache functionality provided by the embedder of webkit

[Michael Nordman]

I'm working on the app cache for Chrome. We've decided to hoist most the
functionality provided by the app cache into Chrome's main browser process,
so we won't be using most of the implementation provided by WebKit. I'd like
to work through what changes to make within WebKit/WebCore to allow an
embedder pull that off. Any suggestions would be much appreciated.
In the code base right now, a single compilation flag enables or disables
everything to do with app cache in WebKit, ENABLE(OFFLINE_APPLICATION). This
turns on/off the scriptable interface bits as well as the backend
implementation within webcore. I think I'd like a way to reuse the
scriptable interface related bits provided by webkit, but to slide a chrome
specific implementation under that interface. One thought was
to separate this single flag into two flags, one for the scriptable
interface bits and the other for the back end implementation.

ENABLE(APPLICATION_CACHE_INTERFACE)
- surfaces the window.applicationCache property
- pulls in the DOMApplicationCache.idl file
- enables event targeting stuff for DOMApplicationCache
- perhaps defines an abstract interface that a c++ class backing
DOMApplicationCache scriptable API must implement

ENABLE(APPLICATION_CACHE_IMPLEMENTATION)  // only valid if INTERFACE is also
enabled
- turns on the rest of the stuff in webkit for app cache, including a
concrete implementation of that abstract interface mentioned above.

Does something along these lines make sense, or perhaps there is another way
to approach this?

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

Re: [webkit-dev] HTML5 Application Cache

[Michael Nordman]

Hi Anders,
Thnx for the pointers to the tests. I hadn't seen them.

Honestly I think the spec needs to be revisited on this thing. The manifest
update/validation scheme in particular has some real problems around
opportunistic caching and dynamically added resources imo. But that aside
for the moment...

* Is this stuff built into shipping Safari or iPhone browsers yet?

* Are any apps, to your knowledge, relying on this stuff yet?

* About the current implementation in the tree.

I noticed all of the I/O was sync, everything including the cached responses
are stored in an SQLite database. Also noticed that when a page that
references an appcache is loaded, all of the resources contained in that
appcache are loaded into memory at page load time. I'm glad you guys don't
consider that as 'done' :)

What would you think of separating response storage (headers and bodies)
from the logical structure of an appcache (set of entries and categories,
namespace definitions, etc). SQLite is a reasonable choice for the logical
structure.  That database could contain keys to response bodies contained in
another repository from which ResourceHandles could be loaded
asynchronously.

Michael







On Wed, Sep 10, 2008 at 11:46 PM, Anders Carlsson <[EMAIL PROTECTED]>wrote:

>
> 9 sep 2008 kl. 20.42 skrev Michael Nordman:
>
>  What is the status of the work-in-progress around the HTML5 AppCache that
>> is in the repository? Is anybody actively working on that now? I'm
>> interested in incorporating support for this feature into Chrome is why I'm
>> asking.
>>
>> Michael
>>
>
> Hey Michael!
>
> As far as the specification goes, the two big parts that aren't implemented
> are opportunistic entries, and dynamic entries.
>
> Also, all I/O is currently synchronous which is of course something that
> we'd like to avoid. The relevant code is (as you probably already know) in
> WebCore/loader/appcache, but also elsewhere in the loader, surrounded by #if
> ENABLE(OFFLINE_WEB_APPLICATIONS).
>
> The code hasn't received a lot of testing (given that the spec is fairly
> new and in flux). Some regression tests are in
> LayoutTests/http/tests/appcache.
>
> Any feedback/comments you have is of course much appreciated!
>
> Anders
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] HTML5 Application Cache

[Michael Nordman]

What is the status of the work-in-progress around the HTML5 AppCache that is
in the repository? Is anybody actively working on that now? I'm interested
in incorporating support for this feature into Chrome is why I'm asking.

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