[webkit-dev] Using Google-URL in WebKit

[Alex Iskander]

WURL? Short, but has the required letters -- though perhaps sounds too  
funny.

Alex

On Oct 2, 2008, at 3:10 PM, David Hyatt wrote:

> Kind of an unrelated note, but it would be nice to rename KURL to
> something else.... e.g., WebCoreURL, URL, WebURL, etc.
>
> dave
>
> On Oct 2, 2008, at 3:07 PM, Brett Wilson wrote:
>
>> About a year ago, Google released the Google URL Parsing and
>> Canonicalization Library (Google-URL) as a separate open-source
>> project: http://code.google.com/p/google-url  It was developed for
>> Chromium with an eye toward being used in other client apps at Google
>> and elsewhere.
>>
>> We think there are a number of advantages of this library over the
>> current KURL code, but I'm not trying to sell anybody on using it or
>> have a big debate about its merits at this time. (Our most important
>> constraint is that we want our application layer and our WebKit layer
>> to agree on parsing for security and other types of "mismatch" bugs.)
>>
>> I have mentioned optionally replacing KURL with an ifdef to a number
>> of WebKit members. The reception has been tentatively yes. There  
>> are a
>> number of reasons to do it:
>>
>> 1. Chromium has this file forked and we can't unfork until at least
>> the header files are resolved. This prevents us from working as close
>> to the tip of tree and would probably limit our WebKit contributions.
>> I would also like to make some changes throughout WebKit that would
>> help our implementation of KURL, but would also help the current
>> implementation. This would only be possible if the code was more
>> unified.
>>
>> 2. It allows the WebKit community to experiment with it. The current
>> state of affairs is that nobody outside of Google knows much about  
>> the
>> library which prevents detailed technical discussions from taking
>> place. Even if full adoption of the library never happens, I think
>> some familiarity with what we did will help future URL parsing and
>> canonicalization work the WebKit community may approach.
>>
>> When everybody can try it out then there can be a much better
>> discussion about whether other ports might want to use it, of the
>> library's strengths and weaknesses, and possible additions and  
>> changes
>> that people may want to see.
>>
>>
>> Current state of affairs:
>>
>> You can see our forked version of KURL.h here:
>> http://src.chromium.org/viewvc/chrome/trunk/src/webkit/pending/KURL.h?view=markup
>> Our implementation is here:
>> http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL.cpp?view=markup
>> http://src.chromium.org/viewvc/chrome/trunk/src/webkit/port/platform/GKURL_unittest.cpp?view=markup
>>
>> We keep the ability to compile with the Google-URL KURL or the  
>> WebCore
>> KURL (we use this for testing) so the final file in the WebKit tree
>> would work similarly. You will notice, however, that this file is a
>> mess and you probably wouldn't want it as-is. It grew organically in
>> such a way as to minimize the changes relative to the upstream  
>> KURL.h.
>>
>>
>> Proposals/Questions:
>>
>> I'd like to add the ability to compile KURL using a Google-URL  
>> backend
>> to the WebKit trunk under some kind of #ifdef. The default WebKit
>> build would see no change in functionality.
>>
>> 1. I don't have any particular preference for the exact ifdef. I  
>> think
>> USE(GOOGLEURL) would be appropriate.
>>
>> 2. I propose to move most of the functions and data additions of our
>> current KURL.h linked above into a KURLPrivate object which is in
>> another header file (or KURLGoogleURL.h?). It would be included at  
>> the
>> top of the file controlled by the ifdef. Non Google-URL projects  
>> would
>> just not use this object/header file. This will eliminate most of the
>> additions while keeping the current code mostly the same. The private
>> section of the class would look like:
>> #if USE(GOOGLEURL)
>>   KURLPrivate p;
>> #else
>>   ... current data members.
>> #endif
>> I can move the current data into a "Private" class as well if you
>> would prefer, which would eliminate further ifdefs but may make it
>> more difficult to follow.
>>
>> 3. Grouping the other code in our current ifdefs should make more of
>> the clutter go away. Alternatively, most of the diffs in the header
>> file (like string getters, isNull, etc.) could be completely
>> eliminated if the functions were implemented in the .cpp file rather
>> than inline. I don't think that this would be a performance hit and
>> would prefer this approach, but others may disagree. There may be  
>> some
>> subset of functions where this makes sense.
>>
>> 4. The Google-URL library would not be checked into WebKit. Those
>> wishing to use it would install it locally in such a place that
>> #include "googleurl/src/foo.h" like Chromium uses now would work.
>>
>> Comments and questions would be welcome,
>> Brett
>> _______________________________________________
>> webkit-dev mailing list
>> webkit-dev at lists.webkit.org
>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev