- Boost - lists.boost.org

Re: [boost] Boost.URL review
by Zach Laine 24 Aug '22

24 Aug '22

On Mon, Aug 22, 2022 at 9:41 AM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > On Sun, Aug 21, 2022 at 6:47 PM Vinnie Falco <vinnie.falco(a)gmail.com> wrote: > > > > On Sun, Aug 21, 2022 at 4:03 PM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > > > ... > > > > It wouldn't be a proper review without at least one person forgetting > > to use "Reply All" :) So here it is, from Zach. I have quoted his > > message: > > > > > This makes sense. The larger issue I'm raising is that a user is > > > going to have a harder time remembering this, if the names don't > > > match. A way to mitigate that is to make this naming rationale > > > explicit, so that user > > > expectations will adjust. I didn't get that this was the pattern from > > > the documentation, though I think you did say it. A call-out > > > specifically noting this would porbably be enough. > > > > Yeah we can do that. > > > > > Hm. By lazy flat_map, do you mean that the positions are computed one > > > step at a time during iteration? is that why they have > > > forward_iterators? > > > > Yes. operator++ and operator-- intelligently find the next param or > > segment using a non-validating parse algorithm (since we know that the > > underlying character buffer has already been validated). > > > > > If so, please document that. It might make a > > > pretty big difference whether I decided to keep using a params object > > > that I need to update a lot, or copy everything over to a proper > > > flat_map or vector to do my work. > > > > Yes I agree, but I thought we did document that. Here, no? > > > > <https://master.url.cpp.al/url/ref/boost__urls__params_encoded_view.html#url…> > > > > We could probably add something here too: > > > > <https://master.url.cpp.al/url/ref/boost__urls__params_encoded_view/iterator…> > > Right, and I understood how those worked. However, I had no idea that > the owning containers were based on the same lazy approach (unless I > misunderstand what you said in this thread...). > > > > This works for an immutable container. It is *very surprising* for a > > > mutable one. The rest of my notes about the containers are predicated > > > on a false assumption that mutability implied non-laziness in the > > > container itself. I think all of these container would be better off > > > referred to as views, and made immutable. All you really need to > > > support is begin/end, plus maybe key-lookup. I suggest you drop the > > > mutability entirely. With mutability, these containers are trying to > > > do two things at once. > > > > Well, that's another way to do it and it certainly would remove > > complexity and simplify the names. Right now we have 8 containers: > > > > segments > > segments_view > > segments_encoded > > segments_encoded_view > > params > > params_view > > params_encoded > > params_encoded_view > > > > All of these containers reference the underlying character buffer of > > the URL (although you can also construct the views from separately > > parsed string views but that's basically the same thing in terms of > > the ownership model being reference-like). > > > > If we remove mutability as you suggest, then we can cut the number of > > containers down to 4: > > > > params_view > > segments_view > > params_encoded_view > > segments_encoded_view > > > > But this leaves us with a problem - how do you modify individual path > > segments and query params? > > Easy -- you just copy them into a flat_map, vector, or whatever. The > 90% use case is just to look at the result of the parse. Also making > the parsing library responsible for mutations you do to the data later > seems unnecessary. If you provide parsing -- including the lazy views > -- and then writing of URLs, and the writing can be done via a generic > container, that's all your library needs, IMO. To be clear: > > Parsing -> lazy_containers -> user mutations outside of Boost.URL -> > writing URLs > > That last step only needs to understand the different kinds of data it > might write, abstractly. That abstraction might be a params_view, a > flat_map, or a std::vector<std::pair<strd::string, std::string>>. > > > How do you do position-based insert and > > erase of elements using an iterator? These features seem kind of > > useful, I'm not sure I want to lose them. > > You won't lose them, because the STL exists. > > > > > Did you mean that it "doesn't" have proper error reporting? Where do > > > > you see this lack of reporting (if that's what you meant)? > > > > > > By "proper" I mean that if the parse fails it should provide an > > > end-user-friendly diagnostic, and optionally quote the line and put a > > > caret under the position that the parse failed (a la the Clang > > > diagnostics). Your non-end-user error reporting is fine. > > > > Oh... hmm.. well, each rule does leave the iterator out-param at the > > spot where an error occurred. But I'm not quite sure how to emit the > > diagnostic - surely you aren't suggesting we write to std::cout or > > std::cerr? Are we using curses or something? Or maybe just plain ASCII > > art? How exactly would this look? > > The diagnostics go to some optional output channel, which might be a > stream or file or logger. If you don't set the output, the diagnostic > is never generated. You set this output in the call to parse*(), as > an optional param -- usually a std::function<void(std::string const > &)>. > > > Thanks to Peter's work on boost::system::error_code, when a parse > > error occurs the error is augmented with file name, line, and function > > name information. And I have worked on adding visualizers so these are > > nicely presented in the debugger. So at least we have that. > > That's really nice for programmers, but it leaves the programmer with > a lot of work to do to present the error to the user. > > Zach Forgot to reply-all *again*. Zach

4 11

boost.url is accpted into boost
by Klemens Morgenstern 24 Aug '22

24 Aug '22

Boost.URL is ACCEPTED into boost without any conditions. The review recommendations were 6 ACCEPT, 1 CONDITIONAL ACCEPT and 1 REJECT. Many points were raised as part of the review, based on which I recommend doing the following: - reviewing which types/functions in the lower-level API are exposed and which ones are not (Ruben Perez' condition) - reviewing pct_encoded_view & encoded_path (as mentioned by Дмитрий) - adding more verbose docs without relying on knowledge of RFC3986 on the user side (mentioned by Richard) - adding more simple examples (recommended by Jon Kalb) - consider adding IRI support in the future (recommended by Rainer) Alan & Vinnie have been very responsive and read all the reviews, which makes it unnecessary to summarize everything. There is only one real point of controversy, namely the only reason for rejection written by Phil Endecott: > More fundamentally, I'm not convinced that this allocation-avoiding > view-rich API style is best for a general purpose vocabulary type > like URL. URL should be a "Keep It Simple" type, accessible to > C++ beginners, with straightforward lifetime semantics. Compare with > std::filesystem::path, which does not try to optimise by actually > being a view. > > Because of these concerns about the basic API design, I believe that > the library should be REJECTED. This argument has however been directly addressed in other reviews, with Seth considering it as an appropriate choice: > Like some of the earlier reviewers, I also have some concerns over introducing > non-owning vocabulary type. I do appreciate the design choice though, because I > think it ultimately fits the Boost ecosystem best - favoring > performance/versatility over ease of use. While Zach Laine considers this as the correct choice: > Overall, I quite like the design. Lazy, lazy, lazy. The fact that > only views into the underlying sequence are returned from the parse is > great, and the fact that there are both owning (url::url and > fixed-capcity owning url::static_url) and view versions of the URL > representations is exactly what I would need as a user. For my decision, the first factor is that more people approved of this particular design choice than disapproved. Secondly it seems to me that the C++ ecosystem is moving towards more view-support. The potential pitfalls can be addressed by coding guidelines (e.g. don't use auto) and do not need to be addressed by constraining libraries. Thus in finding a result, I did not consider Phil's argument to outweigh the other reviews which were considering it an acceptable choice. Other issues were the documentation, the confusion about encoded and decoded data and IRI support. Neither did lead to a rejection, so I'll leave it up to Alan's & Vinnie's discretion to review & address all the raised issues and to engage in further discussion on the mailing lists. Thank you Dmitry, Jon, Phil, Rainer, Richard, Ruben, Seth and Zach for your reviews and Alan & Vinnie for providing yet another boost library.

2 1

Fwd: Review of Boost.url
by Klemens Morgenstern 24 Aug '22

24 Aug '22

Forwarded from an email I received directly. ---------- Forwarded message --------- From: Jon Kalb Date: Mon, Aug 22, 2022 at 11:39 AM Subject: Review of Boost.url To: *- Does this library bring real benefit to C++ developers for real world use-case?* Boost currently contains at least three parsers (Regex, Spirit, and Xpressive) and most application seem to make do with std::string as a URL container implementation. That said, URL parsing is a non-trivial undertaking if done right and need to be done with in a surprising number of applications (because the number of applications that simply store and/or process URLs far out numbers the number of applications that directly use URLs). Having to re-invent the wheel of URL parsing in each of these apps results in both wasted time and poorly implemented solutions. URLs are both general enough and broadly used enough that they a library such as this will be a vocabulary library. *- Do you have an application for this library?* No. * - Does the API match with current best practices?* It appears so. The designed guidelines for the library are the correct ones. The issues that would cause a library such as this to not become widely used would be: - Language version dependency is too recent. - Module dependencies - Slow build times - Relies on dynamic allocation - Relies on exceptions - Not header-only - Not suitable for minimal devices/environments This is pretty much the design requirements for the library. In particular the approaches for minimizing and even avoiding dynamic allocations and functioning with or without exceptions will remove most what would be common stumbling blocks for this library. * - Is the documentation helpful and clear?* The documentation does appear to be thorough with a bit of a gentle introduction. I’d like to see more examples of getting, setting, and removing parameters and a better explanation of how escaping is handled. I suspect there is some magic there that I’d like to understand better. The “Help Card” is a brilliant design but the text in the URL syntax at the top renders improperly in my browser. * - Did you try to use it? What problems or surprises did you encounter?* I only did a read-through of the documentation, but it was thorough enough that I found (and submitted) a few minor corrections needed in the docs. * - What is your evaluation of the implementation?* I didn’t examine the implementation. *Some additional thoughts/questions for the author:* - I read Ruben’s review and tended to agree with and appreciate his thoughts. I did however disagree about exposing the low level parsing tools. If they were not a complete general implementation due to the fact that the library only needed some use cases, so they didn’t represent a completely implemented set of functionality, then I’d be skeptical and wonder if they were well tested. But it seems to me that the tools involved represent a valid and valuable contribution to the community. - I wonder if an operator<() should be defined so that urls could be used as keys out-of-the-box. - I wonder if more scheme constants should be provided. Probably not for the entire official list, but ‘ldap’, ‘mailto’, ‘news’, and ‘telnet’ might be useful enough to include. - This is out of my area of expertise, but I wondered if there might be platforms where instead of using “char” the library should be built on “signed char” or “unsigned char.” I think the URL library should be added to the Boost Libraries. I think will be valuable to the community and the level of professionalism in its design will reflect well on Boost. Thanks. Jon

2 1

boost.url review period has ended
by Klemens Morgenstern 24 Aug '22

24 Aug '22

Based on the amount of reviews I don't think we need an extension to make a clear & well-founded decision, which I hope to be able to announce soon. I would encourage those who didn't find the time to write a review to engage in discussion with Alan & Vinnie who have been very responsive to criticism. Thanks to everyone who participated in the review and discussion.

1 0

[url] Andrzej's notes
by Andrzej Krzemienski 23 Aug '22

23 Aug '22

Hi Everyone, It is somewhat unfortunate that the review happens during the vacation period, therefore I will not be able to devote the amount of time that the library deserves for the review. There is a procedure for extending the review period for a couple of days, but even if it were engaged, I doubt it would have bought me sufficient time. So let me instead offer some loose thoughts. Am I familiar with the problem domain, or do I have a use for this library? My understanding of an URL is that it is a text that I type into my browser (or other tools) that starts with either "http" or "https". I use URLs indirectly by using Boost.Beast, but Boost.Beast offers a higher-level interface for providing parts of URL, and even if this library is accepted, I would use the higher-level interface of Boost.Beast. This is not to claim that there are no uses for the proposed library. It is just my experience. Obviously, Boost.URL fits into the trend of providing many types with strong invariants, which I am very fond of. The fact that you have to set host, port and path separately avoids many bugs: you just cannot create an invalid URL. There is one thing that I do not understand though. I read that: 1. The library is tailored for environments that do not use exceptions 2. url guarantees that it maintains its invariant of always storing a string that represents a valid url. So given the following code executed on a platform with exceptions disabled, what happens? void test(url my_url) { my_url.set_port("twenty-one"); } is it going to kill the program? If so, is this considered a satisfactory solution? I use exceptions in my job, so this is a rather theoretical issue for me, but if I were using urls in no-exceptions environment, I think I would expect an interface like: error_code ec; my_url.set_port("twenty-one", ec); Or something similar. Next, the interface of parse_uri(). This library offers three types for storing (and owing) the characters representing a url: * url * static_url * an unnamed type returned by url_view::persist(). This is good, as in C++ the way the data is stored and laid out is in fact part of the contract. For the same reason we have multiple string types that differ by how memory is allocated, if it is stack allocated, how big the SSO is, what is guaranteed for swap. As a consequence we have a practical engineering issue -- not confined to URLs -- if there is N types storing the same logical data in N different ways, and I have a function returning this logical data, I do not want to offer N functions with N names. I may add a template, or I may use a universal type that can cheaply convert to the N types. How do I do that if I do not want to put templates in the interface of my library? The choice made by Boost.URL may not be optimal, but it is certainly a good starting point in the pursuit of the solution to this problem. I see url_view not as a view but as a universal type for cheaply constructing different containers storing URLs. Of course, this approach is incompatible with the "almost always auto" philosophy, which some people now promote to simply "always auto". My personal opinion is that this AAA philosophy is harmful from the outset and it begs for problems and bugs. If someone adapts the AAA one must accept the responsibility for the problems like the one with dangling references. Next, classes url_base and url_view_base are part of the library's public API. Why? You can keep them as bases but not advertise them in the library documentation. Do you expect any use cases for them? Next. the design in url classes is that it is a mixture of the generic URL as defined in the RFC, and the HTTP-speciffic stuff, such as paths and parameters. It is never the case that I need both of this worlds at the same time: I either need a generic URL that has a password but doesn't have path or params, or I need a HTTP-like URL, where I do not need a password. So if we think about strong types with strong invariants, I never get as strong a type as I would need. For instance, I would never want to pass the password in URL when using Boost.Beast, so having member set_password would only be a potential for bugs. Am I suggesting anything? The only use case that I have for this library is HTTP-like URLS. I would appreciate a http::url class that is tailored for http or even REST protocols. Regarding the docs, while I agree with others that some examples of use cases, such as percent encoding, would be desired, I also note that the documentation stands up to the high standards of of Boost libraries: not only could I figure out the architecture and how things work, but I was able to learn a lot about the problem domain, the URLs, URIs, IRIs, design trade-offs. I really appreciate the effort the authors have put in making the documentation this good. I have two recommendations, though. One, the picture that associates IQs with facial expressions: I strongly recommend that it is removed. It does not bring any technical value, but it seems to be sending a hostile message. Two, the colouring of different parts of URL syntax, as in https://master.url.cpp.al/url/containers.html#url.containers.generic_syntax: it help to quickly grasp things, but it also bring some confusion. For instance, I cannot tell if the double-slash is part of authority, or if the colon is part of the scheme. The colors suggest that they are, but the member functions tell otherwise. I have spent maybe like 30 hours studying the docs, superficially studying the implementation and tried to find if the two match, played with the toy examples in godbolt (gcc 12.1): https://godbolt.org/z/Tbsqrd77M Found a number of bugs and reported them in GitHub. The authors were very responsive and very quickly addressed practically all of them. Every implementation of every Boost library is difficult to read, in my opinion. Boost.URL matches the Boost standard in this respect. I could understand what the functions do, and what they do wrong. I found the solution in function url_view::persist() very innovative: you have one allocation instead of three. I didn't have time to play with path and param views. They seem fine on the surface, but I have a feeling that they would be clumsy to use in practice. I observed that params allow duplicate keys? Is it legal? I am hesitant to give a recommendation for acceptance. I would rather have a longer discussion than a fast decision. I also want to see how the authors respond to these notes. Finally, I want to thank the authors for writing and sharing this library. It is clear that a lot of effort and thought has been invested in it. Regards, &rzej;

6 9

boost.url review
by Christopher Bläsius 22 Aug '22

22 Aug '22

Hi, I'm not a boost developer, but as someone who has to deal with URLs (for calling or implementing Web-APIs) at his job frequently, I want to give my two cents as a most likely user of this library. I hope this is OK (I won't give a recommendation to accept or reject though). I spent about 2.5h integrating the library into our program and tried some simple parsing and constructing of urls. I used MSVC2022 which worked without problems. > - Does this library bring real benefit to C++ developers for real > world use-case? Yes definitely. I believe probably every programmer has written a (mostly crappy) URL-parser before, and I would be more than happy to replace our parser with this library. > - Do you have an application for this library? Yes. Besides parsing incoming HTTP-Requests, I would use it to programmatically construct urls to call external Web-APIs. One of the more common scenarios in our applications is the construction of urls after the user provided some login credentials and often hosts/port combinations. Also a prefix path is often needed (for example to differentiate between a demo or beta service and the real production api). I feel like the current API design lacks a bit in this regard. To construct a new url i did the following: auto url = boost::urls::url{}; url.set_scheme("https") .set_host("special-api.com") .set_port("443") .set_path("/prefix/api/v1/"); url.segments().push_back("applications"); url.segments().push_back(applicationId); url.segments().push_back("devices"); url.params().append("since", "2022-01-01"); The url::set_... methods seem to follow a fluent api design which is nice, but unfortunately they return url_base&. So I can't construct a url inside a function call like: httpClientGet(url{}.set_host(host).set_path("some/path")) Being able to add segments is great. Personally I'm a big fan of overloading the /-operator to append paths like in the filesystem library, because I think this results in more readable code. The example of above could become: httpClientGet(url{host} / "some/path") I really like that the library offers different parse_ functions, so an user can choose the appropriate one depending on the context. But it is a shame that there are no semantic types to go along with them. As mentioned above we often have the case that we have to construct a url by combining a prefix path with the actual path of the resource. As this prefix path has to be absolute and the resource path relative I want to use 2 distinct types for them. It seems to me, the resolve() function has a similar problem. The documentation states that the base url has to satisfy the absolute-URI grammar. Wouldn't it be great to have a distinct type for this? BTW why is there only an authority_view and not an owning container? Seems inconsistent to me. Its nice that there are functions to manually do percentage encoding, but I would prefer (additional) simpler functions which just return a std::string. It would be nice if the library also provided the default port numbers for the schemes. I know the documentation states that this is not part of the URL-protocol, but I gonna need that information if I use the library. > - Is the documentation helpful and clear? Mostly yes. Reading the "Quick Look" page is enough to get started with using the library which I appreciate. I also like the help card, which would be greatly improved by adding links to the reference pages. I skipped / skimmed the Customization and Concept pages. I would recommend not to start your example page with a 700 lines implementation of magnet links, that's super intimidating. Something I missed was a simple example showing that the parse functions also accept unknown schemes like opc.tcp:// for example. Thanks a lot for all your work on providing useful high quality libraries for everyone! Best Regards, Chris

3 2

URL Review
by Phil Endecott 22 Aug '22

22 Aug '22

My review of the proposed Boost.URL library follows. Unfortunately I have been away for most of the review period and I have not been able to spend as much time on this as I would have liked; in particular I have not tried to run any code. But I have looked at the source and documentation. In previous email discussions a few months ago I complained about the dangerous use of non-owning view types in the library interface, and I see that these issues are still present. Specifically, quoting the "Quick Look" docs: result<url_view> r = parse_uri( s ); url u = parse_uri( s ).value(); That's fine for C++03, but since C++11 we have auto, and this is where it becomes dangerous: auto r = parse_uri( s ); There's no indication here that r is a non-owning view and that the caller is responsible for keeping s alive for the lifetime of r. Such errors could be difficult to detect; the code may appear to work correctly much of the time if the storage for s is not re-used. auto u = parse_uri( s ).value(); That's even worse, because we're calling a method called value() but what it returns is not actually a value, it's still a view. A safer API design would, at a minimum, give the parsing function a name with "view" in it. The default, shorter-named function should return a value type. More fundamentally, I'm not convinced that this allocation-avoiding view-rich API style is best for a general purpose vocabulary type like URL. URL should be a "Keep It Simple" type, accessible to C++ beginners, with straightforward lifetime semantics. Compare with std::filesystem::path, which does not try to optimise by actually being a view. Because of these concerns about the basic API design, I believe that the library should be REJECTED. Following are some comments about other more minor issues that I have noticed: I see that there is a method called persist(): std::shared_ptr< url_view const > persist() const; This function returns a read-only copy of the URL, with shared lifetime. The returned value owns (persists) the underlying string. The algorithm used to create the value minimizes the number of individual memory allocations, making it more efficient than when using direct standard library functions. Hmm, so url_view doesn't own the underlying storage, except when it does as a result of this mysterious method. What's the rationale for this? (Have I missed some documentation?) What is sizeof(url) or sizeof(url_view)? I think it must be about 160 bytes, since you store offsets to each of the components. I'm not convinced that this is the best approach. I would be inclined to determine the offsets each time they are needed by the accessor methods. In the constructor, parse to validate the syntax but don't store any offsets. I believe that in the case of the path segments and the query parameters, you are not storing offsets (because the number is variable, and that would need allocations); why not adopt that approach for the other offsets? Making the objects smaller would probably have measurable performance benefits. In your non-view url object, you seem to allocate storage using new char[]. Why not use a std::string? One benefit of a std::string is SBO. Another is that you could provide a move constructor from a string. I find the names of the encoding/decoding views confusing. I would expect a "decoded_view" to refer to underlying encoded data and return equivalent decoded data when it is read from, but you seen to call that an "encoded_view". In your query parameter API, you expose something that looks like a standard associative container except that you call the key and value "key" and "value" respectively, rather than "first" and "second". While I think many of us would agree that those are better names, it does make it more difficult to use this container with generic code than it would be otherwise. I see that you also have a bool called "has_value" in the value_type. I think this is to handle this: ?a=1 // has_value == true && value == "1" ?a= // has_value == true && value == "" ?a // has_value == false Is that correct? Again having this third member in the container's value_type makes generic code more difficult. I would be inclined to use a std::optional for the value instead. In the past I have had situations where it was necessary to specify the case for hex letters in %-encoding; please consider adding this to pct_encode_opts. The Magnet Link example needs a paragraph at the start to say what a Magnet Link is. Regards, Phil.

5 6

boost.url review
by Klemens Morgenstern 22 Aug '22

22 Aug '22

Hi all, the formal boost review of the boost.url library starts today, the 13th of August and will last until and including the 22nd of this month. The library has been developed by Vinnie Falco and Alan de Freitas. The master branch is frozen during the review and can be found here: https://github.com/CPPAlliance/url The current documentation can be found here: https://master.url.cpp.al/ Boost.URL is a portable C++ library which provides containers and algorithms which model a "URL" and understands the various grammars related to URLs and provides for validating and parsing of strings, manipulation of URL strings, and algorithms operating on URLs such as normalization and resolution. Please explicitly state that you either *accept* or *reject* the inclusion of this library into boost. Also please indicate the time & effort spent on the evaluation and give the reasons for your decision. Some questions to consider: - Does this library bring real benefit to C++ developers for real world use-case? - Do you have an application for this library? - Does the API match with current best practices? - Is the documentation helpful and clear? - Did you try to use it? What problems or surprises did you encounter? - What is your evaluation of the implementation? More information about the Boost Formal Review Process can be found at: http://www.boost.org/community/reviews.html The review is open to anyone who is prepared to put in the work of evaluating and reviewing the library. Prior experience in contributing to Boost reviews is not a requirement. Reviews can also be submitted privately to me, and I will not disclose who sent them. I might however cite passages from those reviews in my conclusion. Thanks to Vinnie & Alan for providing us with a new library & thanks for all the reviews in advance. Klemens

9 20

Boost.URL review planned for 13-22 August 2022
by Mateusz Loskot 22 Aug '22

22 Aug '22

Folks, Klemens Morgenstern kindly volunteered [1] as the Review Manager (thanks Klemens!) for the Boost.URL [2], so we have planned the review shortly after the upcoming release of the Boost 1.80. Check the Review Schedule [3] for details! [1] https://lists.boost.org/Archives/boost/2022/06/253225.php [2] https://lists.boost.org/Archives/boost/2022/04/252814.php [3] https://www.boost.org/community/review_schedule.html Best regards, -- The Boost Review Wizards Mateusz Loskot

3 4

boost.url review ends today
by Klemens Morgenstern 22 Aug '22

22 Aug '22

Today is the last day to submit your review for boost.url. Thanks in advance!

1 0