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@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
