The story is even simpler for localStorage. Everything is fairly self
contained and the only way it cares about the main thread is in asserts to
verify SQLite is not used on the main thread.
My guess is that the story for what's considered the main thread will change
for each API much like the spl
On Thu, Apr 30, 2009 at 12:26 PM, Michael Nordman wrote:
> On Thu, Apr 30, 2009 at 11:40 AM, Darin Fisher wrote:
>> On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman wrote:
>>>
>>> On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman
>>> wrote:
>>> >
>>> > + chromium-dev
>>> >
>>> >> Can you please e
On Thu, Apr 30, 2009 at 11:40 AM, Darin Fisher wrote:
> On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman wrote:
>>
>> On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman
>> wrote:
>> >
>> > + chromium-dev
>> >
>> >> Can you please explain what you think has changed since such decisions
>> >> were ma
On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman wrote:
>
> On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman
> wrote:
> >
> > + chromium-dev
> >
> >> Can you please explain what you think has changed since such decisions
> were made (or why it's time to revisit such decisions)?
> >
> > I don't thi
Yup, I'm looking to work thru things in a similar fashion with anders
(original appcache author).
On Wed, Apr 29, 2009 at 11:53 AM, David Levin wrote:
> I think how to split/refactor depends on the feature, understanding the
> current code, and working with the appropriate webkit dev.
> For work
I think how to split/refactor depends on the feature, understanding the
current code, and working with the appropriate webkit dev.
For workers, we thought about how/where it made sense to split the impl for
chrome and talked with a...@webkit about it. There was some iteration as we
figured out thi
+chromium-dev
Designing things in this front/back fashion and re-using the code
entirely in chrome removes at least one high-coefficient of friction
surface rubbing between the chromium and webkit teams. We will likely
pay a higher price up front, but it should pay dividends down the
road. Add an
On Wed, Apr 29, 2009 at 9:44 AM, Dimitri Glazkov wrote:
> I think it's a great idea and the only drawback I can see is the WTF
> dependency and the security implications, which shouldn't be anything
> we couldn't overcome.
Yes, the biggest worry I'd have here has little to do with whether it's o
I think it's a great idea and the only drawback I can see is the WTF
dependency and the security implications, which shouldn't be anything
we couldn't overcome.
The biggest challenges IMHO would be:
1) clearly identifying what backend and frontend mean and where the
separation occurs. I worry (p
On Wed, Apr 29, 2009 at 7:43 AM, David Levin wrote:
> Ideally, there would be one implementation in webkit for html features
> which would allow multiple things:
> 1. Better compatibility across webkit impls. This makes it easier for web
> devs.
> 2. Bugs fixes in one implementation help for bot
On Wed, Apr 29, 2009 at 7:43 AM, David Levin wrote:
>
>
> On Wed, Apr 29, 2009 at 7:02 AM, Peter Kasting wrote:
>
>> On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow wrote:
>>
>>> Darin was there on that lunch and was actually the one who first
>>> suggested running parts of WebCore in the browser t
On Wed, Apr 29, 2009 at 7:02 AM, Peter Kasting wrote:
> On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow wrote:
>
>> Darin was there on that lunch and was actually the one who first suggested
>> running parts of WebCore in the browser to me during a 1:1. :-)
>>
>
> Indeed, we're already planning to
On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow wrote:
> Darin was there on that lunch and was actually the one who first suggested
> running parts of WebCore in the browser to me during a 1:1. :-)
>
Indeed, we're already planning to do it in other ways -- using a text field
as a directly-instant
On Tue, Apr 28, 2009 at 6:26 PM, Evan Martin wrote:
> On Tue, Apr 28, 2009 at 5:59 PM, Aaron Boodman wrote:
> > Is the idea that someday the browser and renderer processes
> > might be separate binaries?
>
> Though this shouldn't drive your decision, about 50% of our code
> weight (at least by o
On Tue, Apr 28, 2009 at 6:31 PM, Michael Nordman wrote:
I have always felt like running the WebCore "backend" in the browser was
elegant
>>>
>>> Yea, but we need a webcore backend to run :)
>>
>> Well last time I looked at this there was already a Database backend :)
>
> Right... inter
On Tue, Apr 28, 2009 at 6:22 PM, Aaron Boodman wrote:
> On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman
> wrote:
>>
>> + chromium-dev
>>
>>> Can you please explain what you think has changed since such decisions were
>>> made (or why it's time to revisit such decisions)?
>>
>> I don't think t
On Tue, Apr 28, 2009 at 5:59 PM, Aaron Boodman wrote:
> Is the idea that someday the browser and renderer processes
> might be separate binaries?
Though this shouldn't drive your decision, about 50% of our code
weight (at least by one metric) is WebKit. You could imagine that the
browser proces
On Tue, Apr 28, 2009 at 6:18 PM, Michael Nordman wrote:
>
> + chromium-dev
>
>> Can you please explain what you think has changed since such decisions were
>> made (or why it's time to revisit such decisions)?
>
> I don't think there was code in webcore suitable for this purpose
> before... html
+ chromium-dev
> Can you please explain what you think has changed since such decisions were
> made (or why it's time to revisit such decisions)?
I don't think there was code in webcore suitable for this purpose
before... html parsing, javascript,sql interpretting... all dangerous
from a securi
Well, the question comes down to this: Can we trust running small amounts of
WebCore in the browser process.
Historically, the answer to running WebCore in the browser has been a
resounding no. Can you please explain what you think has changed since such
decisions were made (or why it's time to re
I have always felt like running the WebCore "backend" in the browser
process with an IPC channel between it and the frontend was a really
elegant design for this problem. And I never really understood why we
weren't allowed to depend on WebCore (even indirectly) in the browser
process. Is the idea
On Tue, Apr 28, 2009 at 5:38 PM, Jeremy Orlow wrote:
> On Tue, Apr 28, 2009 at 5:27 PM, Michael Nordman
> wrote:
>>
>> > In some sense we do have separate process in which to run sandboxed
>> > 'backend' code relevant to multiple renders if the need arises... the
>> > worker process.
>
> The way
On Tue, Apr 28, 2009 at 5:27 PM, Michael Nordman wrote:
> > In some sense we do have separate process in which to run sandboxed
> > 'backend' code relevant to multiple renders if the need arises... the
> > worker process.
>
The way you stated this is a bit odd, but on the surface I guess this cou
23 matches
Mail list logo
