[webkit-dev] Long-term Google-URL integration plans

[Maciej Stachowiak]

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>  
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081002/13634719/attachment.html