+ chromium-dev <chromium-dev@googlegroups.com>
On Tue, Apr 14, 2009 at 1:16 PM, Jeremy Orlow <jor...@chromium.org> wrote:
>> "When you fire an event, will other windows see it? If not, no need for
>> the rest of this... When the event is dispatched, a synchronous message
>> will be sent to the browser process which will be redistributed to all
>> render processes currently subscribed. A nested message loop will be run
>> during the synchronous action. (Also synchronous for serialization
>> purposes.)" <-- I don't understand this. Since storage events originate in
>> the browser, why would the renderer need to send them back to the browser to
>> be re-distributed?
>
> This was talking about DocumentEvent.createEvent which happens in v8 in a
> render process. The only question (and this is something I can answer by
> myself--I just haven't yet) is whether events created in one window are
> supposed to be transmitted to all other windows in that origin. I'd assume
> yes.
I would not expect storage events synthesized in this way to actually
be sent outside of the current window. Strictly speaking, it probably
would be nice if script could not create mock storage events at all.
>> "Cleanup of WebKit's *Storage code" <-- It would be good to start the
>> conversation early with folks from WebKit about how significantly different
>> our implementation of localStorage is. You should expect push-back unless
>> you can adequately justify why a separate implementation is required. I
>> think your design is the right approach, so this should be an "easy"
>> argument to make ;-)
>
> Yup. My next step is starting this conversation with the WebKit people.
>
>>
>> "Rejected alternative approaches" <-- i'm surprised that you don't explain
>> why you are not using the current webkit implementation perhaps with the
>> same VFS approach that we are using for HTML5 database. the only thing
>> missing there is a solution for storage events.
>
> The information was there, but poorly organized. I've fleshed things out
> further and re-labeled things a bit. It's not exactly easy to read because
> there's many possible ways you could re-use WebKit code and there's
> basically a linear relationship between how bad the solution is and how much
> it reuses code.
> Let me know if I missed anything in my analysis.
>
>>
>> the costs to having a separate implementation from apple is non-trivial.
>> ideally you're solution here would be a refactoring of their code to enable
>> you to share some of their code. for example, i would expect that you could
>> share the code that interacts with sqlite.
>
> Because we're handling database operations in the browser process and we
> don't use WebKit there, this is not possible.
> I promise I did put a good deal of thought into how we could share more
> code. My email to WebKit.org will be soliciting ideas, but I think we've
> come up with pretty sound problems for each implementation. Their
> implementation is _very_ rooted in the idea of having one process.
Ultimately we do want to share the same implementation. We should look
at that as a design goal/constraint.
Jeremy's design for this feature is just fine. Unfortunately we can't
use webkit code to realize that design Oh well, too bad, end of
story.... NO. If "their" implementation wasn't so rooted in the idea
of having on process... we could reuse it. So, we have to make "their"
implemetation not so rooted in that. We have to start looking at
webkit as collectively ours too, and contributing to it to make it meet
our needs.
We don't want to hold the Good hostage to the Perfect, so I don't
think this level of reuse should be required in our initial
implemenation of these things, but if we could pull it off... that
would be really nice.
We face the similar issues with the appcache system.
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
