On Oct 2, 2008, at 6:26 PM, Peter Kasting wrote:
On Thu, Oct 2, 2008 at 6:11 PM, Maciej Stachowiak <[EMAIL PROTECTED]>
wrote:
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.
Regards,
Maciej
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
