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
all knows about that?
On Tue, Jun 26, 2012 at 2:54 PM, Michael Nordman micha...@google.comwrote:
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
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
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 dpra...@chromium.org wrote:
We never
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
attribute accordingly.
Adam
On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman micha...@google.com
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
.
On Mon, Nov 14, 2011 at 5:56 PM, Adam Barth aba...@webkit.org wrote:
On Mon, Nov 14, 2011 at 5:41 PM, Michael Nordman micha...@google.com
wrote:
On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth aba...@webkit.org wrote:
For SQLException, there are a hundred exception codes reserved,
static
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
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
wrote:
On Fri, Aug 5, 2011 at 12:09 PM, Michael Nordman micha...@google.com
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
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 micha...@google.com
wrote:
Yes, hashing blobs. Here's the last line of the relevant meeting notes...
In the end, we all agreed
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 jparent+web...@gmail.com wrote:
For Chromium, the http tests aren't very flaky on Mac (I see only 5 flaky
http tests).
xhr.loadAsType with different enum
values for text, blob, array buffer, etc.?
On Fri, Sep 24, 2010 at 5:19 PM, Michael Nordman micha...@google.comwrote:
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
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
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 a...@webkit.org
On Wed, Sep 15, 2010 at 9:15 AM, Darin Fisher da...@chromium.org wrote:
On Wed, Sep 15, 2010 at 8:58 AM, Alexey Proskuryakov a...@webkit.orgwrote:
14.09.2010, в 22:15, Darin Fisher написал(а):
I think it makes sense to extend ResourceHandle.cpp to access the
BlobRegistry singleton in
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 jia...@chromium.org wrote:
This will probably work for most of the
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
On Tue, Mar 9, 2010 at 11:13 AM, Alexey Proskuryakov a...@webkit.org 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
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 jia...@chromium.org wrote:
Hi,
I am looking into the work to support
the iframe from its DOM, does unload not get
fired, do pending xhr's, and do timers continue run such that they survive
after being added to a new parent's DOM how's that work in the magic
iframe scheme?
-Darin
On Mon, Dec 14, 2009 at 2:50 PM, Michael Nordman micha...@google.comwrote:
How
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 m...@apple.com wrote:
On Dec 15, 2009, at 11:09 AM, Michael Nordman wrote:
On Mon
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 dim...@chromium.org wrote:
Hi WebKit,
The recent
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
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
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
bed...@technicalpursuit.comwrote:
All -
I've been discussing the localStorage quota limit over on this bug with
Jeremy Orlow:
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
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
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.
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
On Fri, Aug 7, 2009 at 11:06 AM, Drew Wilson atwil...@google.com 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
On Fri, Aug 7, 2009 at 3:37 PM, Joe Mason joe.ma...@torchmobile.com 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
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
for every connected document.
-atw
On Sat, Aug 1, 2009 at 10:35 AM, Michael Nordman micha...@google.com
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
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
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,
, Michael Nordman micha...@google.comwrote:
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
, в 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
, 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
from worker context without going through a document object (probably required for persistent workers).
-atw
2009/6/2 Alexey Proskuryakov a...@webkit.org
02.06.2009, в 21:59, Michael Nordman написал(а):
Per the spec, shared workers are a distinct browsing context. In
appcache terms
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
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 Orlowjor...@chromium.org wrote:
On Thu, May 28, 2009 at 4:32 PM, Michael Nordman micha...@google.com
wrote:
Can you think of a more
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
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
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
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
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
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
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
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
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 :(
summary (according to me at least:)
The gist of it was that providing appcaching for general use w/o any
special
for the 'persistance' privilege,
could provide such a trigger.
On Wed, May 6, 2009 at 12:09 PM, Michael Nordman micha...@google.com
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
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
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
, this is an intriguing idea.
On Tue, Apr 7, 2009 at 11:16 AM, Darin Adler da...@apple.com 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
On Tue, Apr 7, 2009 at 11:27 AM, Maciej Stachowiak m...@apple.com 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
56 matches
Mail list logo
