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 resultin
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 o
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, J
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
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:
> >>
ustom 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 interes
ou'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 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 d
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"
ve 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...
&
rote:
> 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
> 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
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 anoth
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,
.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 settin
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
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 URL
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 t
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 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.
>>
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 de
> 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 cau
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 indicate
> 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 work
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
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
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=31
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 requ
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." -Geo
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-
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 fing
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 w
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-w
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 worke
> 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
>
ike 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
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 shar
> 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,
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
> 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,
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 написал(а):
>>
>&
inct "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
09/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 easi
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
> 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 thes
ver(/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&#
h 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 mo
> 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...
> 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
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 somethin
> 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
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 pri
> 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
cific 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 q
> 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
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 calle
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 o
f 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
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 usag
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
ebKit 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 brows
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
em
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 a
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 mailin
65 matches
Mail list logo
