On Wed, Apr 29, 2009 at 7:43 AM, David Levin <le...@google.com> wrote:
>
>
> On Wed, Apr 29, 2009 at 7:02 AM, Peter Kasting <pkast...@chromium.org>wrote:
>
>> On Tue, Apr 28, 2009 at 6:38 PM, Jeremy Orlow <jor...@chromium.org>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-instantiable class in the UI, for example.
>>
>> I don't really have much of an opinion on this discussion except that I'm
>> not so negative about the original plan of writing our own backend as Jeremy
>> is. Here are his objections: "From a technical standpoint, it's unclear
>> how testing would work since our test_shell would be testing a different
>> backend from what's in Chromium. It also means we have more code to
>> maintain, and that code is completely off of WebKit's radar. It also makes
>> Apple mad and Dimitri sad. So really, this doesn't seem like a good
>> solution."
>>
>> I'm not sure how test_shell matters w.r.t. testing this backend, since the
>> primary test of the backend (and the frontend?) would presumably be through
>> unittests (w/mocks where necessary), which test the code directly and don't
>> care what backend it's in. test_shell already doesn't have the same code as
>> the main browser for 100 other things.
>>
>> Having code to maintain off WebKit's radar is again not a new situation.
>> I'm not talking about forked stuff, just anything that isn't in WebKit.
>> Having the code in WebKit is a two-edged sword, since when it's there it's
>> gatekeepered on WebKit code review (not a big problem anymore since we have
>> a couple reviewers now) and the WebKit community doesn't seem to try to keep
>> their tree green. So IMO having code in WebKit is still just as much of a
>> maintenance burden on us except with the additional hurdle that it's not in
>> our direct tree.
>>
>> As far as making people mad, feh. Let's decide the right implementation
>> first.
>>
>
> "making people mad" is a simplification of a complex set of things.
>
> 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 both.
> 3. It helps move the web forward better because we may implement a feature
> and our webkit impls will get it.
> 4. The above means that we can make better use of layout tests both in
> knowing that the ones there should probably pass and contributing new ones
> too.
> 5. Giving back to the webkit community is a good thing.
> etc.
>
David hit on most of the points I planned to make. "making people mad" was
obviously a gross oversimplification of the situation. :-)
One thing that I forgot to mention was that the WebKit guys are now starting
to think about making WebKit more attractive to others that want to use a
multi-process model. To me, this is a very noble goal, and fits in with the
original goals of Chromium, so it's something we should try to support--even
if it means a bit more work for us.
>
>
>> But even if the original plan is IMO not so bad, I'm not opposed to the
>> new plans either. People like Darin are much more qualified to comment on
>> what would be *best* and I will be OK with whatever gets decided.
>>
>
I hate speaking for Darin because it's possible that there's some details
here he did not agree with, but I'm pretty sure that most of this is exactly
what we talked about, and that he was supportive of it.
I agree that having our own backend still _could_ be the way to go, but I
guess I'd like to give this a shot first.
Note also that localStorage is actually a pretty simple example. It'll be
interesting to see what things look like for other features, like AppCache.
There, having our own backend probably has more impact, though I'm not sure
if it's a positive or negative impact.
J
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
