[webkit-dev] Join the URL hackathon (already in progress)!

Adam Barth abarth at webkit.org
Tue Apr 13 23:57:47 PDT 2010


I'd like to avoid bikeshedding about the name, but URLCore sounds like
my shade of blue.  :)

Adam


On Tue, Apr 13, 2010 at 11:51 PM, Darin Fisher <darin at chromium.org> wrote:
>
>
> On Tue, Apr 13, 2010 at 11:39 PM, David Levin <levin at google.com> wrote:
>>
>>
>> On Tue, Apr 13, 2010 at 11:35 PM, Adam Barth <abarth at webkit.org> wrote:
>>>
>>> Ah, sorry, I meant to the point where the library was integrated with
>>> the various build systems, etc.  Maybe that's already possible today.
>>> I haven't investigated it in detail.  It probably also makes sense to
>>> talk about correctness between steps (1) and (2), once we have the
>>> tests and their results to compare across browsers.
>>>
>>> Adam
>>>
>>>
>>> On Tue, Apr 13, 2010 at 11:28 PM, Darin Fisher <darin at chromium.org>
>>> wrote:
>>> > #4 is already basically done.  See USE(GOOGLEURL).
>>> > -Darin
>>> >
>>> >
>>> > On Tue, Apr 13, 2010 at 11:17 PM, Adam Barth <abarth at webkit.org> wrote:
>>> >>
>>> >> I think Maciej took notes, but my recollection is as follows:
>>> >>
>>> >> 1) Convert as many of the unit tests to LayoutTests as possible.
>>> >> 2) Land GURL in svn.webkit.org as is.
>>
>> I think there was:
>>    2.5 Change the name from GoogleURL to something else.
>>
>> (WebKitUrl?)
>
> WebKitUrl suggests that it lives more at the higher levels of the code base
> (with the other WebKit* stuff).  How about URLCore living at the same level
> as WebCore and JavaScriptCore?
> -Darin
>
>>>
>>> >> 3) Convert GURL to WebKit style.
>>>
>>> >> 4) Make an ifdef that lets ports switch between KURL and GURL.
>>> >>
>>> >> Once we get to this point, it will be easy to evaluate the performance
>>> >> and correctness impact of switching from KURL to GURL.  Ideally, we'd
>>> >> have a "bake-off" and pick the best parser based on some objective
>>> >> criterion.  If KURL wins the bake-off, we should consider refactoring
>>> >> KURL's parser not to depend on WebCore::String (or really any of
>>> >> WebCore).  If GURL wins the bake-off, we should document (either with
>>> >> comments or tests) which parts of GURL's API is needed by Chromium but
>>> >> not necessarily need by other ports.
>>> >>
>>> >> Adam
>>> >>
>>> >>
>>> >> On Tue, Apr 13, 2010 at 9:17 PM, Chris Jerdonek <cjerdonek at webkit.org>
>>> >> wrote:
>>> >> > Regarding the URL parsing code, could someone that attended the
>>> >> > session list what steps were proposed or tentatively agreed to (of
>>> >> > which the below is the first)?
>>> >> >
>>> >> > Thanks a lot,
>>> >> > --Chris
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Tue, Apr 13, 2010 at 1:46 AM, Adam Barth <abarth at webkit.org>
>>> >> > wrote:
>>> >> >> Have you ever wanted WebKit's URL parsing to be awesome?  Do crazy
>>> >> >> characters in URLs keep you up at night?  Do you love writing
>>> >> >> tests?
>>> >> >>
>>> >> >> If you answered yes to any of these questions, you might want to
>>> >> >> join
>>> >> >> the URL hackathon.  In this hackathon, we're adding a ton of test
>>> >> >> of
>>> >> >> our URL parsing code by adapting a BSD-licensed unit test suit into
>>> >> >> a
>>> >> >> set of LayoutTests.
>>> >> >>
>>> >> >> You can find the instructions and sign-up sheet at following URL:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> http://docs.google.com/Doc?docid=0AZpchfQ5mBrEZGQ0cDh3YzRfMTVnZmZ3dGNmNg&hl=en
>>> >> >>
>>> >> >> Thanks, and happy hacking!
>>> >> >> Adam
>>> >> >> _______________________________________________
>>> >> >> 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
>>> >
>>> >
>>> _______________________________________________
>>> webkit-dev mailing list
>>> webkit-dev at lists.webkit.org
>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>
>
>


More information about the webkit-dev mailing list