[webkit-dev] Changing the implementation of KURL

[Darin Fisher]

The other concern I have is about the stability of the API to the URL
"guts" that GURL living in the chromium repository would depend on.  Anyone
changing the URL guts would need to be careful not to break that contract.
This seems like it might be annoying for those who do not work on chromium.
On Jan 28, 2012 5:43 PM, "Brett Wilson" <brettw at chromium.org> wrote:

> On Sat, Jan 28, 2012 at 5:28 PM, Joe Mason <jmason at rim.com> wrote:
> >> -----Original Message-----
> >> From: webkit-dev-bounces at lists.webkit.org [mailto:webkit-dev-
> >> bounces at lists.webkit.org] On Behalf Of Maciej Stachowiak
> >> Sent: Saturday, January 28, 2012 7:08 PM
> >> To: Brett Wilson
> >> Cc: Benjamin Poulain; WebKit Development
> >> Subject: Re: [webkit-dev] Changing the implementation of KURL
> >>
> >> Let's take some specific examples. Would using WTF::Vector inside the
> >> implementation (not necessarily at the API boundary, just internally)
> >> be acceptable? Or would it be required to use C arrays or std::vector?
> >> Would using WTF's ASSERT family of macros be acceptable, or should some
> >> other form of asserts be used? The are examples I can think of where
> >> "dependencies" could simply be added in the course of trying to get the
> >> code to be in WebKit style.
> >
> > Another big potential dependency would be use of Platform.h and the
> ENABLE/USE/etc system of macros - I could easily see a new feature
> including special processing for a new URL scheme, similar to the way file:
> url's have slightly different parsing rules than http: urls.  In this case
> we'd want to wrap the special handling in ENABLE(feature).  (Arguably the
> url class should be flexible enough that you don't have to hardcode special
> handling for a scheme, though.)
>
> I don't see that as being much of an issue. Google Safe Browsing can
> always write their own Platform.h that does what they need.
>
> Brett
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120128/5587972b/attachment.html>