[webkit-dev] Long-term Google-URL integration plans
mjs at apple.com
Thu Oct 2 18:40:01 PDT 2008
On Oct 2, 2008, at 6:26 PM, Peter Kasting wrote:
> On Thu, Oct 2, 2008 at 6:11 PM, Maciej Stachowiak <mjs at apple.com>
> It sounds to me like you are saying that you would not be willing to
> consider using the current KURL implementation in Chrome, even it
> turns out to be materially better, and it gets exposed with a low-
> level interface that you could use in non-WebCore pieces of Chrome,
> and ends up free of problematic dependencies or license terms.
> Is that a correct interpretation of what you are saying?
> We will always be willing to take a better engineering solution over
> a worse one.
Likewise. If we all agree on that, then there is no problem. It
sounded to me like Brett either did not agree in this case, or was so
confident of the superiority of Google-URL that he did not think it
was even worth considering the alternative.
> Given that I don't think KURL _does_ canonicalization right now it's
> hard for me to understand what it means to suggest that the current
> KURL could be "materially better".
Extra functionality would certainly count as one way of being
materially better. Those are the kinds of facts that I think we should
look at (in addition to comparing behavior, testing perf, etc). But
for what it's worth, while KURL does not have a canonicalize operation
that's separate from parsing, it does canonicalize as a side effect
parsing. It's possible (maybe even likely) that it doesn't apply apply
all desirable canonicalization rules.
> And we spent a lot of time on the performance, footprint, and
> compatibility of this code, since it's used all over; so I have
> confidence in its qualities.
I similarly have some confidence in the qualities of KURL (even
knowing that there is room for improvement) but not so much that I'd
be willing to bet on it without comparison testing.
> But I think the intent here is to make it possible to build whatever
> the right thing is and use it everywhere. If there is something low-
> level that is materially better than what we have to offer as a
> starting point (the current low-level code underlying GURL), whether
> that already exists or gets created/improved over time, then both
> Chromium front-end code and WebCore benefit from using it.
Sounds good to me.
> The prospect of WTF types in general tends to make me leery, since
> using one can bring in dependencies on others, and we wouldn't want
> to bring more dependencies than necessary into the Chromium front-
> end code; but if this were confined to using existing lightweight
> WTF types that didn't depend on other types, for cases where the
> current low-level GURL code is already rolling its own types, then
> there's probably no loss to anyone by doing that (and a small gain
> for embedders already using WTF types).
Yes, I can see that pulling in an open-ended set of dependencies would
defeat the purpose of the exercise for you guys. I would not expect
that to happen.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev