[webkit-dev] Long-term Google-URL integration plans
I posted earlier about adding an ifdef for the Google-URL library in KURL.h. I thought I would also explain the current thinking on the long term plans, which a number of people have expressed concern about. The current ifdef approach is an incremental way for us to move forward, both with out merge of forked WebCore files, and toward a more unified URL handling infrastructure. We are open to a wide variety of solutions. We have a requirement that we can use the same backend for our application-layer URL handling without adding WebKit types. It would need to have two modes: a 16-bit character mode for web pages, and an 8-bit character mode for interpreting network traffic. Where the code lives and what format the code is in are less important. I think the best goal to have at this point that satisfies everybody's requirements is that there be an interface layer that KURL uses. This interface would basically be the url_canon and url_parse interfaces in Google-URL. The initial implementation of these interfaces would be the Google-URL code, and they would live in some directory inside WebKit in the WebKit coding style. This code would have no WebCore, WTF, or STL types in it. Applications like Chromium could (if they wanted)) implement their own URL objects on top of this interface, just like KURL would be implemented on top of it. Other applications could also use this code without taking a dependency on WebKit (there has been some interest expressed about Google-URL for this reason). This is basically splitting the current library into two, along layers which are already designed into it (with the exception of one std::vector in url_util.cc which is a bug). The current Google-URL project would likely be abandoned. The WebKit community currently has little knowledge about this library today. Predicting the final outcome will be impossible until the community has some experience with this code. They may find that the code or approach of the library is unacceptable, and we'll have to find another way forward. Assuming that the Google-URL library is largely seen as an improvement to the codebase by the WebKit community, what I have outlined here would be a perfectly acceptable solution to us. Brett ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Long-term Google-URL integration plans
This plan seems generally ok, a few comments: On Oct 2, 2008, at 4:43 PM, Brett Wilson wrote: > I posted earlier about adding an ifdef for the Google-URL library in > KURL.h. I thought I would also explain the current thinking on the > long term plans, which a number of people have expressed concern > about. The current ifdef approach is an incremental way for us to move > forward, both with out merge of forked WebCore files, and toward a > more unified URL handling infrastructure. > > We are open to a wide variety of solutions. We have a requirement that > we can use the same backend for our application-layer URL handling > without adding WebKit types. It would need to have two modes: a 16-bit > character mode for web pages, and an 8-bit character mode for > interpreting network traffic. Where the code lives and what format the > code is in are less important. > > I think the best goal to have at this point that satisfies everybody's > requirements is that there be an interface layer that KURL uses. This > interface would basically be the url_canon and url_parse interfaces in > Google-URL. The initial implementation of these interfaces would be > the Google-URL code, and they would live in some directory inside > WebKit in the WebKit coding style. I'd like to not assume up front that the code used to implement the URL parsing core will be Google-URL. Maybe Google-URL's code will turn out to be better, maybe the current KURL implementation will. I'm willing to keep an open mind about this until we can do some comparisons. Are you also willing to keep an open mind about which implementation is the basis of a shared one? I also do not find the current interfaces of url_canon or url_parse particularly congenial, so we should also keep an open mind on what the interface to this code would look like. Is that ok with you? > This code would have no WebCore, WTF, or STL types in it. I'd like to relax this and say WTF types should be ok as long as they are moved to the same dependency level and have an equally liberal license. For instance, I don't see the win of the URL library having a separate class for a resizable buffer with possible stack backing store for small buffers, rather than using WTF::Vector. Similarly, if any unicode processing is needed, it would be nice to use WTF's unicode library abstraction layer for ports that do not use ICU but have a different source of unicode functionality (I think that's only the Qt port currently). > Applications like Chromium could (if they wanted)) implement their > own URL objects > on top of this interface, just like KURL would be implemented on top > of it. Other applications could also use this code without taking a > dependency on WebKit (there has been some interest expressed about > Google-URL for this reason). This is basically splitting the current > library into two, along layers which are already designed into it > (with the exception of one std::vector in url_util.cc which is a bug). > The current Google-URL project would likely be abandoned. > > The WebKit community currently has little knowledge about this library > today. Predicting the final outcome will be impossible until the > community has some experience with this code. They may find that the > code or approach of the library is unacceptable, and we'll have to > find another way forward. Assuming that the Google-URL library is > largely seen as an improvement to the codebase by the WebKit > community, what I have outlined here would be a perfectly acceptable > solution to us. I have a copy of the library checked out from SVN (have for quite some time) and I have studied the code. But I will admit I don't know much about how well it works. Anyway, I am ok with this something along these lines with the caveats mentioned above. Does anyone else have comments? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Long-term Google-URL integration plans
On Thu, Oct 2, 2008 at 4:58 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > I also do not find the current interfaces of url_canon or url_parse > particularly congenial, so we should also keep an open mind on what the > interface to this code would look like. Is that ok with you? Some background: url_parse and url_canon are designed to be very low-level and flexible. They are not actually intended to be used directly by an application. They are intended to be used by a wrapper object that can be written using any generic string type, 8- or 16-bit string inputs. The current interface certainly isn't perfect, but I think it's about what you get with these requirements. On top of this layer is the url_util layer. This is what GURL and KURL are really implemented in terms of, and it's actually quite simple. It calls the correct lower-level functions in the ways that they were intended to be called. Sometimes it's convenient to bypass this, and we occationally do. It's nice that the application has the option to do either. You can see the GURL object has both a relatively clean interface and relatively little logic inside of it. As you say, the exact interface to the lower layers is unimportant as long as it meets the needs of both objects. >> This code would have no WebCore, WTF, or STL types in it. > > I'd like to relax this and say WTF types should be ok as long as they are > moved to the same dependency level and have an equally liberal license. For > instance, I don't see the win of the URL library having a separate class for > a resizable buffer with possible stack backing store for small buffers, > rather than using WTF::Vector. Similarly, if any unicode processing is > needed, it would be nice to use WTF's unicode library abstraction layer for > ports that do not use ICU but have a different source of unicode > functionality (I think that's only the Qt port currently). > >> Applications like Chromium could (if they wanted)) implement their own URL >> objects >> on top of this interface, just like KURL would be implemented on top >> of it. Other applications could also use this code without taking a >> dependency on WebKit (there has been some interest expressed about >> Google-URL for this reason). This is basically splitting the current >> library into two, along layers which are already designed into it >> (with the exception of one std::vector in url_util.cc which is a bug). >> The current Google-URL project would likely be abandoned. >> >> The WebKit community currently has little knowledge about this library >> today. Predicting the final outcome will be impossible until the >> community has some experience with this code. They may find that the >> code or approach of the library is unacceptable, and we'll have to >> find another way forward. Assuming that the Google-URL library is >> largely seen as an improvement to the codebase by the WebKit >> community, what I have outlined here would be a perfectly acceptable >> solution to us. > > I have a copy of the library checked out from SVN (have for quite some time) > and I have studied the code. But I will admit I don't know much about how > well it works. I think when you can run it in Safari, you'll feel more strongly about it one way or the other :) [moved from the beginning of the message] > I'd like to not assume up front that the code used to implement the URL > parsing core will be Google-URL. Maybe Google-URL's code will turn out to be > better, maybe the current KURL implementation will. I'm willing to keep an > open mind about this until we can do some comparisons. Are you also willing > to keep an open mind about which implementation is the basis of a shared > one? You should not be accepting this code because you're doing a favor for us. You should accept it because you think that there's a good chance you will eventually end up with a better URL implementation. If you don't think this is the case, please let me know. I would rather spend my efforts maintaining a fork of KURL than arguing about why you should do something you don't want. I've probably spent only one day all year merging KURL, so the status quo will be significantly less work for me personally. If we check it in with ifdefs, you evaluate the details of the implementation, and you think that the current KURL code is better than Google-URL, then I think this status quo is easier for both of us. Nothing precludes this from happening. This is why I was very clear about "evaluation" and that you may find it "unacceptable," which is OK. I will volunteer to do the work necessary to factor the code as necessary if you decide you like it. Brett ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Long-term Google-URL integration plans
On Oct 2, 2008, at 5:28 PM, Brett Wilson wrote: > > [moved from the beginning of the message] >> I'd like to not assume up front that the code used to implement the >> URL >> parsing core will be Google-URL. Maybe Google-URL's code will turn >> out to be >> better, maybe the current KURL implementation will. I'm willing to >> keep an >> open mind about this until we can do some comparisons. Are you also >> willing >> to keep an open mind about which implementation is the basis of a >> shared >> one? > > You should not be accepting this code because you're doing a favor for > us. You should accept it because you think that there's a good chance > you will eventually end up with a better URL implementation. If you > don't think this is the case, please let me know. I would rather spend > my efforts maintaining a fork of KURL than arguing about why you > should do something you don't want. I've probably spent only one day > all year merging KURL, so the status quo will be significantly less > work for me personally. 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? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Long-term Google-URL integration plans
On Thu, Oct 2, 2008 at 6:11 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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. 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". 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. 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. 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). PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Long-term Google-URL integration plans
On Oct 2, 2008, at 6:26 PM, Peter Kasting wrote: On Thu, Oct 2, 2008 at 6:11 PM, Maciej Stachowiak <[EMAIL PROTECTED]> 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Long-term Google-URL integration plans
On Thu, Oct 2, 2008 at 6:40 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote:
>
> On Oct 2, 2008, at 6:26 PM, Peter Kasting wrote:
>
> 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.
>
My main concern is that the code be parameterized (templatized) properly so
that we can use it with the data types that are compatible with Chromium
code (STL) as well as WebKit code (WTF). I don't think it is desirable to
depend on WTF directly since that would introduce WTF types into elements of
Chromium that are otherwise quite divorced from WebKit (e.g., our network
stack). This is why I told you that I supported a type neutral core w/
interfaces like KURL and GURL that cater to a particular choice of container
types. I think if you study the code and our usage of the code in Chromium,
you will see that this is a reasonable requirement.
At this stage, I think it is difficult to know exactly what the proposed
code will look like. However, IMO the general direction that we arrived at
is good since it is a path that will allow all WebKit-based products
(including Chrome!) to converge on a better solution for URL parsing and
canonicalization.
That said, I am on the same page as Brett. In the short term, the #ifdef he
proposed is not going to be hard for us to maintain in the interim or
forever if we end up agreeing to disagree about the future of KURL. We
really do not wish to burden anyone with having to maintain our #ifdefs (or
anything related to our port!), but a few #ifdefs can go a long way to
helping free us to work on more important WebKit issues. We really abhor
#ifdefs, but sadly they are sometimes the best way.
We can also do a version of what Brett proposes without introducing any
#ifdefs if that would be preferrable.
#include "KURLPrivate.h"
class KURL {
public:
// interface methods
private:
KURLPrivate p;
};
If we then put KURLPrivate.h into a subdirectory, it will be easy to change
that out at build time. Bottom line: we don't want to cause existing WebKit
maintainers any extra headache here.
Regards,
-Darin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
