How about: boost proposed logo Of course if people liked it, I do it as an svg. Patrick

On Sat, Jan 30, 2010 at 10:49 AM, Patrick Horgan <phorgan1@gmail.com> wrote:

Patrick Horgan wrote:

...

How about:

boost proposed logo

http://dbp-consulting.com/images/boostproposed.png

Sorry, forgot I couldn't post images on this list, hope the link goes through;)

That's alright, though I made one for cpp-netlib to address Robert's concerns. It's here and was a quick hack on the original PNG: http://cpp-netlib.github.com//boost.png HTH -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

On Sat, Jan 30, 2010 at 8:57 AM, Dean Michael Berris <mikhailberis@gmail.com> wrote:

On Sat, Jan 30, 2010 at 8:44 AM, Robert Ramey <ramey@rrsd.com> wrote:

...

Would it be possible for some one to craft a logo which has the word "Proposed" plastered over the normal boost logo.  This would better communicate the true intention.  That this a library which is intended to become part of boost, but which hasn't been officially accepted yet.

I'd love to get my hands on something like that.

And I've made one for cpp-netlib. You can check that now -- please let me know if this meets your standards for clearly indicating the the library is Proposed for future inclusion into the Boost C++ Library. Thanks again for pointing it out. If I've hurt anybody's feelings I apologize and hopefully this addresses concerns about the use of the Boost logo in the documentation. Have a good day and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Bjørn Roald wrote:

I think boost should have guideline for this in documentation templates and guidelines and probably in the wiki. A standard set of logo designs used at various stages in a proposal life-cycle may be good, I made some proposal designs and uploaded to the vault as logo/boost_logo_alternatives.zip

http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_logo_alternatives.zip&directory=logo&

I really like what you did, and I LOVE that you used GIMP. If you need any help converting to svn via inkscape for resizability (yes, it's a word--I just made it up), I'm happy to help. If not, I'm happy to cheer:) Patrick

Bjørn Roald wrote:

...

and I LOVE that you used GIMP. If you need any help converting to svn via inkscape for resizability (yes, it's a word--I just made it up), I'm happy to help. If not, I'm happy to cheer:)

I have used Inkscape to vectorize before. It is awesome! But if we are going to make these scalable, then I suspect there are better starting points than the web version of the boost logo that I had at hand. Maybe even a vector based original. Even Inkscape has limitations.

The SVG version of the logo is available at: http://people.inf.elte.hu/cad/etc/graphics/boost/ You need a specific font installed, I believe, called "Denmark". I though this is in SVN, but cannot immediately find it. HTH, Volodya

Bjørn Roald wrote:

On Saturday 30 January 2010 12:41:17 pm Vladimir Prus wrote:

...

Bjørn Roald wrote:

...

The SVG version of the logo is available at:

http://people.inf.elte.hu/cad/etc/graphics/boost/

You need a specific font installed, I believe, called "Denmark". I though this is in SVN, but cannot immediately find it.

Great Volodya,

Patrick, if you will like to - please go ahead and make scalable versions.

The full archive of the logo variations is at <http://svn.boost.org/svn/boost/website/workplace/logo/>. It has the original, from the artist, versions. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

On 01/31/2010 10:06 AM, Patrick Horgan wrote:

Rene Rivera wrote:

...

Bjørn Roald wrote:

...

...elision by patrick

...

Great Volodya, Patrick, if you will like to - please go ahead and make scalable versions.

The full archive of the logo variations is at <http://svn.boost.org/svn/boost/website/workplace/logo/>. It has the original, from the artist, versions. Please review http://dbp-consulting.com/boostvariantslogo.html

FWIW, I liked it much more when the "proposed for" etc. notes were blue. Red breaks the style of the logo and the page as a whole.

On Sunday 31 January 2010 08:06:09 am Patrick Horgan wrote:

Please review http://dbp-consulting.com/boostvariantslogo.html

Great stuff Patric. Layout is very good on all of them. I think it is good to use the red color where attention to that part is desired. This does not necessarily apply to the "using" and "powered by" variants, hence blue may be better there. Just my opinion. Other than that - the only thing that make me unhappy is, as you discuss in a different post, the need to remove "for" in "under construction for" variant. Only: under construction boost c++ libraries It is kind of saying all of boost is under construction - not good! I do not know if two lines are any good for layout, so what about looking for alternative texts first: "designed for" we have that, can be used but not necessarily the same meaning as it indicate design is completed. "in work for" do not know if i like that "proposal sketch for" maybe "library sketch for" maybe "proposal draft for" maybe "library draft for" maybe "preliminary proposal for" too long "preliminary library for" too long ~~~ . .. If we go with two lines, the text is much simpler -- I suggest: ---- sketch proposal for boost c++ libraries ---- used for request for interest submission ---- preliminary proposal for boost c++ libraries ---- used for versions prior to submission for review ---- proposal for boost c++ libraries ---- used for submission for review ---- accepted for boost c++ libraries ---- may be used for submission between accept and first release ---- boost c++ libraries ---- may be used by accepted submissions shall be for boost releases -- Bjørn

Patrick Horgan wrote:

Please review http://dbp-consulting.com/boostvariantslogo.html

The "Accepted For" and "Proposed For" logos are very good. Both nicely take into account the current formal review practices :-) The style of the "powered by" and "using" logos is probably not appropriate for their intended usage. The logos are too large, and the "powered by"/"using" should not be in red. The "designed for" and "under construction" logos are unclear. The intention of the logo would be to make clear the relation to boost. But "under construction" is a statement about the library itself, and "designed for" may be a statement, but not a clear one. Wasn't there a "rejected proposal for" logo? I guess it was dropped for the same reason that "under construction for" was renamed to "under construction". How about "in preparation for" and "rejected by"? These would at least make a statement about the relation to boost. Regards, Thomas

Andrey Semashev wrote:

IMHO, the "rejected" logo makes a disservice for the library, as it marks it as something of inappropriate quality for Boost in eyes of users.

I think the original proposal comes from http://lists.boost.org/Archives/boost/2010/01/161356.php and the changes to the original proposal were explained in http://lists.boost.org/Archives/boost/2010/01/161386.php The original proposal described two different use cases for the logos. The first use case was:

Any library or system using boost may use the "powered by" or "using" variants. The second use case was: A standard set of logo designs used at various stages in a proposal life-cycle may be good

So the "rejected proposal for boost" or "rejected by boost" logos (which you summarized by "rejected") are meant to describe a specific stage in a (possible) proposal life cycle. An example of a library in this stage is Boost.Utility/Singleton: http://lists.boost.org/Archives/boost/2008/01/132777.php

Therefore I'd like it to be rephrased to something more neutral, such as "unofficial extension" or something of that kind.

I guess "unofficial extension" tries to communicate the same meaning as "designed for", but it is hard for me to nail down what it exactly wants to communicate. But I agree that this also describes a specific stage in a (possible) proposal life cycle. I guess an example of a proposal in this stage is Boost.CMake. But lets face it, this specific stage in a life cycle is not something that boost currently encourages or is able to handle specifically well. (This is different from the "rejected" stage of the life cycle, which is not so extraordinary for boost proposal after all.) Regards, Thomas

Andrey Semashev wrote:

...

I think the original proposal comes from http://lists.boost.org/Archives/boost/2010/01/161356.php and the

Yes, I read that post, but it misses one (quite common, I believe) case, when the rejected library continues to live outside of Boost, with little or no intention to resubmit the review. It is still designed to fit into Boost infrastructure, so I don't think that "powered by" or "using" variants are adequate.

Perhaps it wasn't a good idea to split one of the use cases into many logos with different meanings. Perhaps one "draft for boost" logo would be enough, so it would be clear that the library is somehow associated with boost, but not an accepted boost library. And a rejected library can just keep using that "draft for boost" logo, if it wants to. There might be more than one logo for that use case (like "powered by" and "using" for the other use case), but there would be no difference in the intended meaning of these logos. Regards, Thomas

Thomas Klimpel wrote:

I guess "unofficial extension" tries to communicate the same meaning as "designed for", but it is hard for me to nail down what it exactly wants to communicate. But I agree that this also describes a specific stage in a (possible) proposal life cycle. I guess an example of a proposal in this stage is Boost.CMake. But lets face it, this specific stage in a life cycle is not something that boost currently encourages or is able to handle specifically well. (This is different from the "rejected" stage of the life cycle, which is not so extraordinary for boost proposal after all.)

A library rejected is either still proposed and could say that, or it's withdrawn and should say anything. "rejected for", or "rejected", or "rejected by" all sound so negative, and can't imagine anyone using these logos. Patrick

On Sunday 31 January 2010 10:33:56 pm Patrick Horgan wrote:

Andrey Semashev wrote:

...

On 01/31/2010 02:56 PM, Thomas Klimpel wrote:

...

Wasn't there a "rejected proposal for" logo? I guess it was dropped for the same reason that "under construction for" was renamed to "under construction". How about "in preparation for" and "rejected by"? These would at least make a statement about the relation to boost.

IMHO, the "rejected" logo makes a disservice for the library, as it marks it as something of inappropriate quality for Boost in eyes of users. Therefore I'd like it to be rephrased to something more neutral, such as "unofficial extension" or something of that kind.

LOL! I can't imagine anyone would proudly proclaim "my software was rejected by boost!" If they are rejected by boost though, they have no business showing a boost logo associated with their software (unless they're using boost, then they could have the using boost logo).

I agree that things like using should be blue. I feel that things that say, "I'm not a part of boost yet but I want to be", should be in red so that people notice that this isn't boost.

I'm glad to see some good conversation here. What's the difference between "proposed for" and "under construction for", and is it a big enough difference to have both?

No I don't think so. The idea was to somehow capture the state of the submission. "Under construction for" was saying it was not ready for submission. "Proposed for" or "Proposal for" was for saying this is the proposed version. I have changed my mind and suggest to not use the logo for communicating details of submission or release state. Other means are simpler and better. I am thinking there are 3 valid use-cases that deserve logo variants. 1. Official boost - the original logo 2. Preliminary Boost - need placeholder logo in proposed documentation for planned and actual submissions for review, this logo should not lead to the misinterpretation that this is official Boost. 2. Using Boost - probably a smaller almost icon sized logo that does not take over the users website :-) -- Bjorn

On Sunday 31 January 2010 11:20:29 pm Patrick Horgan wrote:

I've put some new/improved/resized icons up to reflect the discussion.

http://dbp-consulting.com/boostvariantslogo.html

These are all good as far as layout. I think the two-liners work fairy well. I dislike the "under construction" variant. If we keep it it should be changed to "under construction for" two-liner, but I think "preliminary proposal for" cover tat use case better. my vote is: preliminary proposal for proposal for using With the option of cutting the first and adding a requirement to add proposal state information in a mandatory text legend at start of documentation. -- Bjørn

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Stewart, Robert Sent: Monday, February 01, 2010 2:36 PM To: boost@lists.boost.org Subject: Re: [boost] [logo] Boost logo variants for use in unofficial or unreleased boost documentation - was C++ Networking Library Release 0.5

Bjørn Roald wrote:

...

On Sunday 31 January 2010 11:20:29 pm Patrick Horgan wrote:

...

I've put some new/improved/resized icons up to reflect the discussion.

http://dbp-consulting.com/boostvariantslogo.html

FWIW, my preference is for * Red "Developing for", blue Boost (not yet in the review queue, or reviewed but not accepted - yet - revision in progress?). (I would expect that people would have got past the "assessing interest" stage and got something in sandbox SVN to use this logo, but let's not be too legalistic?). * Red "Proposed for" blue Boost (in the Review queue).

I like the red text for the not-yet-accepted-library logos. I like the blue for "powered by."

Red makes quite clear what is likely to be subject to change, perhaps without notice. * Blue Boost logo as now (reviewed and accepted - even if not yet released). and * Blue "Powered by" blue Boost (transparent?) (uses Boost code). Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com

Stewart, Robert wrote: (...but patrick has done a lot of elision...)

Bjørn Roald wrote:

...

I dislike the "under construction" variant. If we keep it it should be changed to "under construction for" two-liner, but I think "preliminary proposal for" cover tat use case better.

I agree that "for" is needed with "under construction," but splitting "under construction for" into two lines won't look right any way you try it.

I put up an "under construction for" for your perusal. Wouldn't it be fun to replace the graphic at left with some sort of construction equipment? I'd whip it up, but I suspect that changing the graphic rather than overlaying text as we are would legally dilute the logo. Is this logo a registered trademark? If it is, I think that you can add new and different icons, but derivative ones can't change the basic registered form. I could just be making that up. Does anyone know the law?

I like the idea of limiting the variations of the logo.

There seems to be consensus on that, but the discussion is only about 3 1/2 people.

...

preliminary proposal for

I don't like that. Until something is proposed, it isn't a proposal. How about "developing for" or "creating for?" The present participle implies ongoing work.

I would maintain that it would be a bit premature to put a boost icon on a project before it's a proposal. Even with PROPOSAL FOR, there will be a problem some day, with someone who has never contacted boost and has nothing to do with boost will quite unethically associate a PROPOSAL FOR icon with their software to gain panache. A DEVELOPING FOR icon would encourage this and is also somewhat unclear. Next thing you know people will want one that says "has nothing to do with";)

...

proposal for

I like Patrick's "proposed for" better. The past participle implies that the library has been proposed and is awaiting review.

n.b. it wasn't mine, Robert Ramey suggested "proposed", and Dean Michael Berris did an original png graphic. They started this discussion in another thread. I am merely the channel who puts these things on the graphics;) I like "proposed for" better too, for your reasons, because it's more active, and because graphically it works better. So I'd like to trim down the web page so I can move the discussion to sizes that should be available. Are there any that you feel are right out? These MIGHT BE REMOVED from discussion: (feel free to argue for ones you like or to propose others--although I seem an authoritative voice, I'm really just pushy;) o DESIGNED FOR - unclear what this means--designed to work with, or work using? o PROPOSAL FOR - proposed for is better o ACCEPTED FOR - after you're accepted you could just use the boost logo. o SKETCH PROPOSAL FOR - seems unclear to native US English speakers what this means. o PRELIMINARY PROPOSAL FOR - as far as boost is concerned it's either a proposal at some stage or not and if it is you could use PROPOSED FOR. o UNDER CONSTRUCTION FOR - same arguments as PRELIMINARY PROPOSAL FOR, seems that you could just use PROPOSED FOR. I like the idea of keeping both POWERED BY and USING even though they essentially mean the same thing, because the first is more exciting and edgy, which is what some projects would want, but others would prefer to use staid old USING. I definitely prefer POWERED BY myself, but think that there would be wide variance in opinion. So, that would leave the USING/POWERED BY pair, the PROPOSED FOR, and the regular boost icon which already exists and isn't part of this discussion. That's my 7 3/4 cents. Same comments on PROPOSED FOR as UNDER CONSTRUCTION FOR--wouldn't a crane or bulldozer look cool for the graphic? Patrick

Patrick Horgan wrote:

So, that would leave the USING/POWERED BY pair, the PROPOSED FOR, and the regular boost icon which already exists and isn't part of this discussion. That's my 7 3/4 cents.

+1 (As a consequence, in my case the logo in the quickbook generated doc would then link to the "powered by boost" logo. I guess that is essentially also what you were arguing for, i.e. that not yet proposed or rejected libraries should use one of the USING/POWERED BY pair.)

Same comments on PROPOSED FOR as UNDER CONSTRUCTION FOR--wouldn't a crane or bulldozer look cool for the graphic?

-1 Regards, Thomas

Paul A. Bristow wrote:

Thomas Klimpel wrote:

...

Patrick Horgan wrote:

...

So, that would leave the USING/POWERED BY pair, the PROPOSED FOR, and the regular boost icon which already exists and isn't part of this discussion. That's my 7 3/4 cents.

+1 [...]

I'm confused - I understood that the idea of the "Powered by Boost" was for third party software to announce that they were (proudly we hope) *using* Boost software in their software.

So if you are developing something that you hope will become part of Boost, you *don't* use this - you need a "Developing for" or "Proposed for " logo - I think the latter should only be used if in the review queue.

Then we need a "Developing For" or equivalent logo in addition, because "Proposed for" seems to be reserved for the review queue. I would be also OK with this. I just tried to come closer to a final agreement. (So I was agreeing with Patrick, and explicitly spelled out what it means in my specific case.) Regards, Thomas

Thomas Klimpel wrote:

Then we need a "Developing For" or equivalent logo in addition, because "Proposed for" seems to be reserved for the review queue. I would be also OK with this. I just tried to come closer to a final agreement. (So I was agreeing with Patrick, and explicitly spelled out what it means in my specific case.)

But before it gets on the review queue, it doesn't really have an association with boost and could only use the powered by (if it was using other boost libraries of course)--wait, that was your point wasn't it! Now I get it:) n.b. I think a pre-PROPOSED FOR icon would look really silly, no? My position on this, is that your quickbook generated doc for not-yet-on-review-queue software could link to POWERED BY icon iff your software uses other libraries, but that otherwise it would be premature to claim any association with boost. That's what started this whole discussion on another thread, the use of a boost logo for something that was on review bothered some. The use of a PROPOSED FOR icon for something not on the review queue or any other icon other than the POWERED BY (if appropriate) would also bother some. Patrick

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Patrick Horgan Sent: Tuesday, February 02, 2010 6:37 PM To: boost@lists.boost.org Subject: Re: [boost] [logo] Boost logo variants for use in unofficial or unreleased boost documentation - was C++ Networking Library Release 0.5

Thomas Klimpel wrote:

...

Then we need a "Developing For" or equivalent logo in addition, because "Proposed for" seems to be reserved for the review queue. I would be also OK with this. I just tried to come closer to a final agreement. (So I was agreeing with Patrick, and explicitly spelled out what it means in my specific case.)

But before it gets on the review queue, it doesn't really have an association with boost

I disagree strongly with this. Stuff in SVN *does* have an association with Boost. We need to have a way of saying that this is "Hoping to be proposed for review for Boost". An important part of the review process, IMO, is getting a user base - this is where the bugs get flushed out, and the unpopular design decisions flagged up. To leave it all to a final review is far too late. (It often leads to rejection, sometimes improvement and re-submission, but all too often, loss of promising code). This is why I long argued for a formal "Not accepted, Under development and worth giving a try but don't count on it too much yet" status. A different logo (Developing for Boost? Candidate for Boost? Development for Boost? Prototype for Boost? RFC for Boost? ) would provide this. Perhaps we still haven't got the right words yet? We also need a way to encourage users to try developing stuff - and give their feedback. This is how things get refined. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com

Patrick Horgan wrote:

Paul A. Bristow wrote:

...

We need to have a way of saying that this is "Hoping to be proposed for review for Boost".

Really?

...

An important part of the review process, IMO, is getting a user base - this is where the bugs get flushed out, and the unpopular design decisions flagged up. To leave it all to a final review is far too late. (It often leads to rejection, sometimes improvement and re-submission, but all too often, loss of promising code).

Having a special logo for this state doesn't help that process along, does it? My suggestion was to use the "powered by" logo as a placeholder in such cases. Does that detract from a work in progress? Does it impede testing and identifying bugs?

...

This is why I long argued for a formal "Not accepted, Under development and worth giving a try but don't count on it too much yet" status.

I think that is well handled by having a page on the Boost web site with a list of just such projects, provided those with write access are willing to take on that chore.

...

A different logo (Developing for Boost? Candidate for Boost? Development for Boost? Prototype for Boost? RFC for Boost? ) would provide this. Perhaps we still haven't got the right words yet?

I can understand that a library developer would like to gain notoriety by association with Boost while developing a library for possible inclusion in Boost, but does a logo for that spur the author to do anything s/he wouldn't have done already? Does such a logo inform those examining such a library about something not already known?

I really like Candidate for Boost or maybe Submission Candidate for Boost

One isn't a candidate for anything until one announces one's candidacy. In this case, the announcement of candidacy is a formal review request. If there's to be a logo for libraries under development but not submitted for review, "developing for" works well. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Vicente Botet Escriba

Rob Stewart wrote:

...

Patrick Horgan wrote:

...

Paul A. Bristow wrote:

...

This is why I long argued for a formal "Not accepted, Under development and worth giving a try but don't count on it too much yet" status.

I think that is well handled by having a page on the Boost web site with a list of just such projects, provided those with write access are willing to take on that chore.

There is already a wiki page: https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction

I wasn't certain that page is quite what Paul was describing. Being a Wiki makes it less well controlled and that might be a factor. Maybe its enough to have a prominent link to that Wiki page from the main web site (under Development, perhaps?). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Paul A. Bristow wrote:

...

Stewart, Robert

...

Paul A. Bristow wrote:

...

...

...

An important part of the review process, IMO, is getting a user base - this is where the bugs get flushed out, and the unpopular design decisions flagged up. To leave it all to a final review is far too late

...

Having a special logo for this state doesn't help that process along, does it?

Yes IMO.

I don't understand how. Would you care to explain?

...

My suggestion was to use the "powered by" logo as a placeholder in such cases.

...

Does that detract from a work in progress?

Yes - I think this muddies the waters.

IMO "Powered by" should only be for those (Google, Microsoft, Nokia...) using Boost for their *finished end products*, not for libraries for submission to Boost. It's a 'thank you Boost' message - like the web listing of products/companies that acknowledge that they are using Boost.

(Aside - I can't conceive of a new Boost library that doesn't use Boost, so there is no need to acknowledge it?)

Doesn't that allow for using a "powered by" logo as a placeholder for libraries under development is appropriate since they use Boost? The logo isn't wrong and its merely a placeholder for when the library is accepted and can use the "real" logo. A rejected library maintained outside Boost, rather than for resubmission, would correctly use the "powered by" logo without need to change. Thus, the driver is for a library to want to move past the "powered by" stage to the official logo stage. Using a "developing for" logo means a rejected library not resubmitted should change to "powered by." How can we enforce that? If all such libraries start with "powered by," they'll be correct when they are developed without further intent to be submitted and the author of accepted libraries will gladly expend effort to use the official logo. My point is that, long term, using "powered by" as a placeholder ensures that libraries have the right logo.

...

...

...

This is why I long argued for a formal "Not accepted, Under development and worth giving a try but don't count on it too much yet" status.

...

I think that is well handled by having a page on the Boost web site with a list of just such projects, provided those with write access are willing to take on that chore.

Agreed the wiki site is helpful - but marking the docs with a specific logo is also helpful in a different way.

I'm not convinced, but there are plenty of others that can contribute to the decision.

The main thing I think we are all trying to avoid is not-reviewed docs with the Boost logo, implying that they are reviewed and released.

Yes, but also that rejected libraries not imply acceptance.

...

...

...

A different logo (Developing for Boost? Candidate for Boost? Development for Boost? Prototype for Boost? RFC for Boost? ) would provide this. Perhaps we still haven't got the right words yet?

I can understand that a library developer would like to gain notoriety by association with Boost while developing a library for possible inclusion in Boost, but does a logo for that spur the author to do anything s/he wouldn't have done already?

I think it does.

I don't get it.

...

Does such a logo inform those examining such a library about something not already known?

Yes - it says this is getting to a usable state, and perhaps nearing proposal for review.

If all libraries, at any stage of development, can use the "developing for" logo, it means nothing but that the library is intended, one day, to be submitted. There is no implication of quality or nearness to review.

...

...

I really like Candidate for Boost or maybe Submission Candidate for Boost

If there's to be a logo for libraries under development but not submitted for review, "developing for" works well.

"Developing for Boost" works fine for me too, but "Under construction for" works too.

Three words, with a long one in the middle, doesn't fit nicely. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Patrick Horgan wrote:

I'm sorry to be such a nudge, but I don't want to create a problem similar to the one that we are trying to solve.

I'm not sure if my experience is typical, but I've seen a number of projects that used the boost logo because the developers had aspirations to be included in a boost release. I never had much trouble telling what was "official" boost, though... if it was in the release off the boost website, I concluded it was boost... otherwise, not. Erik

Stewart, Robert wrote:

One isn't a candidate for anything until one announces one's candidacy. In this case, the announcement of candidacy is a formal review request. If there's to be a logo for libraries under development but not submitted for review, "developing for" works well.

I've mentioned before that I think "developing for" is unclear, but I haven't really said what bothers me about it. The sense you mean, I think, is "I'm developing this software for possible future inclusion in boost". The one that I worry about is, "I'm acting as some sort of (quasi-)official representative of boost, and I'm developing this for them". It's as if I was a contractor or some super duper special boost guy, and I was "developing for" boost under contract. After all, if I sent you an email saying that I was working on a library that I was "developing for" Apple, it's what you would assume. Now I know that it doesn't happen like that with boost, but most people in the software community don't read this list, don't know anything about how boost works, and could just as easily come to that conclusion as the other. It could easily be misconstrued because it doesn't clearly say, "I'm developing this with the thought that I might submit it to boost and see how it goes." Patrick

I agree. Might I suggest "Potential" or "Unreviewed" Thank you Michael. What about the issue of the implication of a connection though? If the library is withdrawn, or never makes it into

Michael Fawcett wrote: the review process, does it go through life with "UNREVIEWED BOOST C++ LIBRARIES" attached to it? That sounds like it's still a boost library, just in a special category.

above the Boost logo in place of "Developing for"? Disregard the plurality mismatch since we do that already when the "Boost C++ Libraries" logo appears with a single library. It's a given that it's "Part of" the "Boost C++ Libraries". It will also be a given that an unreviewed potential library is "Part of" the "Potential Boost C++ Libraries"

I don't think that there's anything about "UNREVIEWED BOOST C++ LIBRARIES" that automatically tells anyone unfamiliar with the process that the implication is that it isn't a boost library at all. And it isn't. It may or may not later be submitted. After applying for submission, a review manager may or may not accept it for submission. It could go through it's life with that icon, and it says too much. The library may be wonderful, or may be crap, but it's not a boost library. Same arguments for "POTENTIAL BOOST C++ LIBRARIES". It's not clear that it is not in some way a boost library. I think it says too much. I'd rather go with one that may say too little, i.e. "POWERED BY BOOST C++ LIBRARIES", as a placeholder in the docs for the library for the reasons that Robert gave earlier in this discussion. Patrick

Stewart, Robert wrote:

Here's another idea: "for use with." That would apply to all libraries that claim some affinity to Boost, whether because they employ techniques that permit use of various Boost types, concepts, etc., because they provide pieces that can be plugged into Boost libraries, or because they are being developed with the intent to submit for review.

I removed a bunch of the icons and added "for use with" so that you can see it. I was torn between red or blue on the "for use with" http://dbp-consulting.com/boostvariantslogo.html I think of "FOR USE WITH" as the catchall--it could mean anything almost. Patrick

Paul A. Bristow wrote:

Patrick Horgan

...

I removed a bunch of the icons and added "for use with" so that you can see it.

I don't like it much.

I doesn't make clear if the library is intended for submission to Boost (or is just using Boost libraries or in Boost style).

That's the point. It is supposed to be widely applicable.

I like red for making clear that it's "Not an accepted Boost library".

I agree.

What happened to "Developing for" in red icon?

As Patrick pointed out several times, that can imply official Boost association as in, "Boost asked me to develop this for them."

This is what I believe we need for the original posters question.

I thought that "for use with" would be enough different from "powered by" to permit its broad application to libraries developed with the intention of being submitted as well as those just done in the Boost style or with interaction with Boost as a design goal.

It's in danger of turning into a bike shed issue ;-(

It seems like we're fairly close. We know what the original logo means. We agree that "powered by" is suitable for use by applications and libraries that use Boost and are willing to advertise as much. One open question is whether we need a third logo for libraries being developed with the intent to submit to Boost for review and, if so, what it should say. There's also the question of whether a logo is needed for libraries developed to interoperate with Boost without intention of becoming part of Boost. I had hoped that "for use with" would satisfy both of the latter uses. I know you're convinced that a special logo is necessary for libraries being developed to submit for review. You haven't convinced me of that. I don't know if you've convinced anyone else. If others are convinced, then its a question of what that logo should say. "Developing for" and "under construction for" are wrong for the purpose. "Proposed for" is only correct for a library for which a review request has been made. (I picked those three because they are currently in Patrick's example set.) You have yet to answer my concern that allowing a library to use a being-developed-for-possible-inclusion-in-Boost logo means that an author must take positive action to replace the logo for a rejected library left to languish or further developed outside of Boost. A less specific logo, such as "powered by" or "for use with" works fine for such libraries without the author needing to take any action. This ensures that libraries don't suggest more than they should in such cases, though it doesn't meet your desire to label libraries as on their way to review. Perhaps a good first step, if nothing better appears soon, is to add "powered by" and "for use with" and use them for a while as I've described. If someone finds the magical phrase for a logo that means being-developed-for-possible-inclusion-in-Boost without requiring that it be removed later to avoid overstating the relationship if nothing comes of the library, then we can add that logo at that time. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

I've trimmed the samples down to the three mentioned, and have examples of the powered by at 50, 100, 150, 200, and 250 pixel width. See http://dbp-consulting.com/boostvariantslogo.html Patrick

On Sunday 07 February 2010 06:02:48 pm Paul A. Bristow wrote:

OK to start a new thread?

We need to smoke out if there are any real strong objections. As far as process, there may be a need to for a formal review, mini review, or vote count of some sort. This is somewhat unclear as this is not really a library proposal. Logos are however no small issue. However, I think simple yes/no vote counts has been used in the past. You should ask how to proceed at this point, and if anybody can arrange what is required for formally approving the logos. The best would be is that review manager / vote counter are not directly associated with the proposal. A new thread is a good idea at this point. The discussion has settled on two logo use cases and the two logos presented in the proposal are as good as any other proposed. A new "Proposal ..." thread signals a proposal that the general boost list should be able to say yes or no too. So, I say yes - go ahead with the new thread. -- Bjørn

On Sun, Feb 7, 2010 at 12:02 PM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:

Many are concerned at the 'Dilution of the Brand Identity': so we propose two new logos:

1  For projects that use Boost and would like to acknowledge this - with thanks

(in addition to the 'Using Boost' listing on the website)

"Powered by" - logo for all projects *using* Boost.

2  For projects that are written with Boost 'in mind', perhaps for submission, but are *not yet reviewed and accepted*

"For use with"  - logo for projects having some association with Boost, but are *not 'official'*.

(Many like red text to signal that this is NOT (yet) a Boost approved library).

What about the 3rd one - 'proposed for' ?

See

http://dbp-consulting.com/boostvariantslogo.html  (produced by Patrick Hogan)

By the way, I think the added text is too small. Tony

Paul A. Bristow wrote:

Patrick Horgan

...

So here is a draft text for starting a new thread:

" Subject: Proposal for new variants of the Boost logo.

There are many projects springing up, often with smart documentation using the Boost Logo, and there are many more products, for sale and for free, that use Boost libraries.

I'm not sure what you're trying to say with the phrase, "smart documentation."

Many are concerned at the 'Dilution of the Brand Identity': so we propose two new logos:

Alternative introduction: "With so many new projects appearing with documentation brandishing the Boost logo, as directed currently for review submissions, there is growing concern that the Boost "brand" or "identity" is being diluted. To correct that, we propose a new logo for use by libraries not yet accepted by Boost. "Furthermore, while we have a "Using Boost" page on the web site, the Boost brand can be better advertised and established if products using Boost have a logo for indicating the use of Boost libraries and, perhaps, as a way of expressing thanks for those libraries. "Therefore, we propose that Boost adopt two new logos. One will add the words 'for use with' to the standard logo, and the other will add the words 'powered by' to the standard logo. You can see our current ideas for those logos at http://dbp-consulting.com/boostvariantslogo.html, as created by Patrick Horgan."

1 For projects that use Boost and would like to acknowledge this - with thanks

(in addition to the 'Using Boost' listing on the website)

"Powered by" - logo for all projects *using* Boost.

2 For projects that are written with Boost 'in mind', perhaps for submission, but are *not yet reviewed and accepted*

"For use with" - logo for projects having some association with Boost, but are *not 'official'*.

This list can now be eliminated and this additional explanation can be added: "Projects that are written in the style of Boost libraries, perhaps with the notion of being submitted for review, shouldn't use the official logo as it signals an association that does not exist. Therefore, we propose that all projects of this sort, including libraries being proposed for inclusion in Boost, use the new 'for use with' logo. "A fourth logo was suggested for libraries submitted for review that adds 'proposed for' to the standard logo. That logo is thought to lend additional credibility to authors that shepherd a library far enough along to be put on the review queue. However, there is concern that if such a library is reviewed and rejected, the author can choose to not further develop and resubmit the library or to carry on the library's development outside of Boost. In such cases, the 'proposed for' logo implies too much about the relationship between that library and Boost. Thus, the "for use with" logo is thought to be a safer alternative for proposed libraries. "Notice that the 'powered by' logo uses a phrase in keeping with the word 'boost.' An earlier suggestion was 'uses,' but the current proposal makes a more powerful statement. Because there is a direct association between Boost and such libraries and applications, the phrase 'powered by' is rendered in the same blue as the rest of the logo text."

(Many like red text to signal that this is NOT (yet) a Boost approved library).

"By contrast, the 'for use with' logo, which merely indicates a potential association with Boost, and is to clearly show that libraries have not been accepted by Boost, uses red text to draw the attention to the variant text. Perhaps another color or stylistic convention is more suitable, but we haven't thought of anything else."

http://dbp-consulting.com/boostvariantslogo.html (produced by Patrick Hogan)

Horgan

(These will be available in bitmap, png and svg formats ready to be used in html and pdf docs). "

"There are questions of where to put such logos in SVN, how to document their use, etc., and we must tackle those, of course, but we'd like to focus on three questions at present: "1. Should Boost adopt new logos? "2. Are the two proposed logos the right ones to add? "3. Is the rendering of the new logos good? "Please be sure to answer those three questions when replying, even if you have other thoughts or suggestions."

OK to start a new thread?

I think we're ready to do so. I like what you started with, but I thought it could be improved a bit. I hope you like it. I'm fine with any variation of yours and mine you'd like to send.

PS Exactly where they go and size can be decided later?

Yes.

SVG are best for pdf generation (and are embedded into the pdf of course).

PNG are best for html (because IE doesn't support svg - shame!). html need to copy the pngs from Boost site so that docs can be zipped self contained.

I purposely tried to focus attention away from such things at this point. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Stewart, Robert wrote: ... all elisions by patrick...

It seems like we're fairly close. We know what the original logo means. We agree that "powered by" is suitable for use by applications and libraries that use Boost and are willing to advertise as much. I'm pretty sure we've agreed on "proposed for" as well, no? One open question is whether we need a third logo for libraries being developed with the intent to submit to Boost for review and, if so, what it should say. There's also the question of whether a logo is needed for libraries developed to interoperate with Boost without intention of becoming part of Boost. I had hoped that "for use with" would satisfy both of the latter uses.

...

Perhaps a good first step, if nothing better appears soon, is to add "powered by" and "for use with" and use them for a while as I've described. And proposed for?

After that, the next issue is: o what pngs are generated by default from the svg, i.e. what pixel width (small medium large?) o where in the tree do they go, (I assume near the current logo) o how to make them available. The "POWERED BY" logo should probably be easily available from www.boost.org. The others can probably live in the source tree because the people that use them will probably have boost as source o documentation for setting up the documentation for a project will need to change. Patrick

Stewart, Robert wrote:

Patrick Horgan wrote:

...

Stewart, Robert wrote:

...

Perhaps a good first step, if nothing better appears soon, is to add "powered by" and "for use with" and use them for a while as I've described.

And proposed for?

I've argued against that one because a proposed library can be rejected or can languish in the queue. If the library isn't accepted, then the author must take positive action to remove the close association that logo creates, though I admit that logo does not imply acceptance by Boost.

Ok, I've got it, "FOR USE WITH" will be used as the placeholder then. Somehow I missed that.

...

o how to make them available. The "POWERED BY" logo should probably be easily available from www.boost.org. The others can probably live in the source tree because the people that use them will probably have boost as source

The original "powered by" should be with the others, but there should be a simply means, from the web site, to grab HTML to embed in a web site plus the logo to copy for inserting into an application or library's documentation.

Or it could be like the W3C icons where they just make the icons available for download via a link and it's up to you to come up with appropriate html. Patrick

Paul A. Bristow wrote:

I'm confused - I understood that the idea of the "Powered by Boost" was for third party software to announce that they were (proudly we hope) *using* Boost software in their software.

So if you are developing something that you hope will become part of Boost, you *don't* use this - you need a "Developing for" or "Proposed for " logo - I think the latter should only be used if in the review queue.

For me, the discussion evolved to the point of reducing the logo set to just "powered by" and the official logo. For libraries being developed, "powered by" is a placeholder that implies some dependence on the Boost tools (config, Test, etc.) at least. For libraries in the review queue, it's a placeholder for the official logo upon acceptance. Such usage is no different than now occurs only such libraries use the official logo. There certainly could be other variations, but then you get into the hassles of trying to determine the exact requirements for applying each logo and enforcing correct usage. With the two logo system, there are three possibilities: a library is part of Boost and so uses the official logo; a library or application uses Boost and so uses the "powered by" logo, which includes the placeholder scenarios above; no Boost logo.

I think that getting some plugs is an excellent idea.

(especially if it is the 'big boys' like Adobe, Apple, even the Mighty Microsoft !)

No argument _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

My suggestions: RFC for under review for works with Tony

2010/2/1 Bjørn Roald <bjorn@4roald.org>:

On Monday 01 February 2010 01:41:40 am Gottlob Frege wrote:

...

My suggestions:

RFC for

ok, works with me.

...

under review for

When you read this 10 years after the review, this says it is still under review.

After the review it either becomes accepted (boost logo) or rejected - which I was suggesting:

...

works with

It is unclear to me what this is used for.  Is it works with as in using, or as in compatible with?

in the sense of compatible with. A nicer word for 'rejected'. Could also be used for anything not yet under review, etc. I didn't mention using, but I think "powered by" is good. I purposely didn't describe my meanings, in order to see if they were clear.

I appreciate the contribution by Bjoern Roald and Patrick Horgan and I am going to use Bjoern's variant of the "proposed by" logo for the next updates of my own library docs. As with boost libraries as a whole, I think we should strive to foster a consistent style, simplicity and elegance. This implies to have (1) as few additional logos as possible and (2) logos that try to seamlessly and artistically integrate into the typographical style that is currently used in boost and boost quickbook. Because of (2) I think that the red colored additions of Patrick's logo are less suitable because they add a new (and a very strong) color to the logo and to the color family of the whole quickbook style. 2010/2/1 Thomas Klimpel <Thomas.Klimpel@synopsys.com>:

Patrick Horgan wrote:

...

LOL!  I can't imagine anyone would proudly proclaim "my software was rejected by boost!"

Well, not exactly "proudly proclaim". But the library author might take a "time off" [...] it would be used rarely anyway.

...

If they are rejected by boost though, they have no business showing a boost logo associated with their software

It's not so easy. That they were rejected during a formal boost review doesn't necessarily mean that they are no longer associated with boost. The current agreement is to limit the number of different logos, especially no special logo for rejected libraries.

I agree with both points. My suggestion is this: * Only two additional logos (1) proposed for boost (2) compliant to boost Libraries that have been proposed on the list and generated interest can use logo (1). In order to be acceptable for a formal review, the library has to become boost compliant. * Boost centric directory structure * Implementation of various boost conventions * Portability * Dependent on std and boost libs only * Sufficient documentation. * Sufficient tests ... to mention only the most important ones. A library that is not boost compliant will not reach a formal review because the review manager should check and reject any non boost compliant submission. The process from the first RFC to the formal review implies already a great amount of work and an evolutionary process that greatly improves the libraries quality. This is (1) first of all an achievement of the library author, (2) an achievement of other developers through discussion and (3) an achievement of the boost community that produces standards and guidelines. So a library that reaches the state of formal review, even if rejected has gained quality and usefulness by the process of becoming boost compliant. A library that has been rejected in a formal review can stay "proposed for boost" if there is a chance for resubmission that the author wants to pursue or can be labeled "boost compliant", a state reached by committing the library to the boost review process. An accepted library simply carries the original boost logo. Cheers Joachim

2010/2/1 Stewart, Robert <Robert.Stewart@sig.com>:

Joachim Faulhaber wrote:

...

As with boost libraries as a whole, I think we should strive to foster a consistent style, simplicity and elegance. This implies to have (1) as few additional logos as possible and (2) logos that try to seamlessly and artistically integrate into   the typographical style that is currently used in boost and   boost quickbook.

I agree with both of those, but not to your application of (2).

...

Because of (2) I think that the red colored additions of Patrick's logo are less suitable because they add a new (and a very strong) color to the logo and to the color family of the whole quickbook style.

Without making that text stand out from the normal logo, it is too easy to miss the variant nature of the not-yet-accepted logos.  The red clearly draws attention and makes the not-yet-accepted status clear.  Whether to use red or another color or stylistic deviation is less important than to make the logos obviously distinct from the official logo.

I see your point. But I tend to prefer style over ease of recognition here, knowing that boost users are quite intelligent and alert people.

...

My suggestion is this:

* Only two additional logos   (1) proposed for boost   (2) compliant to boost

Libraries that have been proposed on the list and generated interest can use logo (1). In order to be acceptable for a formal review, the library has to become boost compliant. * Boost centric directory structure * Implementation of various boost conventions * Portability * Dependent on std and boost libs only * Sufficient documentation. * Sufficient tests ... to mention only the most important ones.

I disagree with your distinctions.  A proposed library can be compliant.

They are not supposed to be exclusive.

The important factor is whether it is on the review queue, which implies that it has undergone some level of scrutiny.

I have my doubts, if the review wizards have the time to check every library in depth. In my experience the crucial point is to find a review manager. He will check more strictly before giving his name and time for a project.

...

A library that is not boost compliant will not reach a formal review because the review manager should check and reject any non boost compliant submission. !

That's a hurdle for getting onto the review queue.  It doesn't require a special logo.

...

The process from the first RFC to the formal review implies already a great amount of work and an evolutionary process that greatly improves the libraries quality. This is (1) first of all an achievement of the library author, (2) an achievement of other developers through discussion and (3) an achievement of the boost community that produces    standards and guidelines.

So a library that reaches the state of formal review, even if rejected has gained quality and usefulness by the process of becoming boost compliant.

If a library hasn't been accepted, nothing can be said about it other than that it hasn't been accepted.

theoretically, but practically I have rarely seen submitters that dare to violate boost conventions. And if they do they won't find review managers.

A library can be "compliant" and be a horrible idea.

this case, I think, is really rare.

That status doesn't help as I see it.

I think it does. It enables contributors to win even if not accepted into the core. And for boost ... there are additional associated libs in the public domain that witness the influential power of boost. This could be a win-win game for people who invest time and energy but fail finally and the boost community. Was it a bad thing to go for it, because of label: *rejected* Or has the project gained quality in the process: *boost compliant* Best, Joachim

Thomas Klimpel wrote:

It's not so easy. That they were rejected during a formal boost review doesn't necessarily mean that they are no longer associated with boost. The current agreement is to limit the number of different logos, especially no special logo for rejected libraries. I'm perfectly OK with this. The status of a library rejected during review is quite similar to the status of a library that is not yet proposed for review, so I think the same logo could be appropriate for both. A quite common case will also be that a rejected library is simply not touched again after it was rejected. So this could be also OK (="time freeze").

My 3 cents. If they have been rejected, but are still working to improve the proposal, then they are still proposed for. If they have abandoned the effort, either by abandoning the software completely, or by deciding to continue without the software outside of any association with boost, then they don't need a special icon for that state. They might be using boost, but are not in any other way associated with boost. Patrick

Joachim Faulhaber wrote:

2010/2/1 Patrick Horgan <phorgan1@gmail.com>:

...

My 3 cents. If they have been rejected, but are still working to improve the proposal, then they are still proposed for. If they have abandoned the effort, either by abandoning the software completely, or by deciding to continue without the software outside of any association with boost, then they don't need a special icon for that state. They might be using boost, but are not in any other way associated with boost.

Why are you assuming that failing in a formal review implies abandoning association to boost. This can be an understandable reaction if grand and unrealistic expectations were held that did not meet reality.

If the library was rejected, and the author chooses not to try again, that library has no association with Boost other than that its author is/was a Booster. If the library is further developed outside Boost, in the spirit of Boost, but without seeking acceptance into Boost, then nothing can be known of its state, particularly relative to Boost, except that it wasn't accepted by Boost. It may be great, it might even be accepted today were the author to retry, or it might be horrible. Therefore, it mustn't bear a Boost logo except, perhaps, the "powered by Boost" logo to avoid the suggestion that Boost approves of the library.

Other people may experience they learned a lot and have another try in a different library project.

What the author learns from Boost and the review process isn't relevant to putting a Boost logo on the rejected library.

My idea to introduce a state "boost compliant" could be an acknowledgement of the simple truth, that the library, in the process to be prepared for formal review gained quality and implements all the conventions and properties that are necessary (but not necessarily sufficient) for a boost library to be accepted.

If the library was rejected, it was good enough for a review manager and the review wizards to put it up for review. That means something, there's no doubt. Since the library was rejected, and without locating and reading the review results, nothing is known about the quality of the library. Applying any Boost logo besides "powered by" or similar implies more than is known. (I'm speaking in generalities. Of course someone could review a specific library, consider the review results, etc., and determine whether that library good enough to grant permission to use some variant Boost logo. In the general case, however, no such determination can be made merely based upon a library's having been rejected.) Putting a "Boost compliant" logo on a library lends the Boost name to that library and gives tacit approval of that library. Since the library was rejected, that hardly seems wise. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Vladimir Prus wrote:

The SVG version of the logo is available at:

http://people.inf.elte.hu/cad/etc/graphics/boost/

You need a specific font installed, I believe, called "Denmark". I though this is in SVN, but cannot immediately find it.

It's right there with the logo at http://people.inf.elte.hu/cad/etc/graphics/boost/fonts/DENMARK.TTF This makes it so easy. The only thing that might not be obvious, is to use <ALT>-> to adjust the spacing between characters. Denmark 13 point seems about right. You can do each chunk of text in a separate layer with visibility, just like with GIMP. As soon as you have formalized agreement on the different stages/modes, it will only take a few minutes. If you have any questions feel free to ask:) Patrick

On Sunday 31 January 2010 01:02:46 am Patrick Horgan wrote:

...

Any opinion on the various font sizes? On my screen the smallest become fairly blurry, but seems to still provide fair readable for randomly selected bypassing testers. As it is a lot of anti-aliasing needed I am eager for opinions on how it is to read and if the message is too toned downed or too highlighted in the various logo variants?

Ok, as a design idea, I think that boost is the primary message, so in the same way that the C++ Libraries part is subordinate to the boost part, so should be the added parts, and I'd like them to match, stylistically, the part that says C++ Libraries, but just a tiny bit smaller.

agree.

For the first, one, PROPOSED FOR, I set it up as follows: font: URW Gothic L Semi-Bold Oblique size: 8 letter spacing: 4.0

Did you get all that set up in Inkscape...? did not find a way to set letter spacing?

That does a pretty good job of matching the weight and spacing of the C++ Libraries phrase.

Of course for things like under construction for, even changed to under construction, which doesn't quite mean the same thing, these settings don't work, it's too big to fit in the space between b and t, which is probably why you had the font size 7 for it. So, what do we do? You can change the spacing to 3 for that one, which is ok, or if you move the top of the text box up and change it to centered, you can get UNDER on top above CONSTRUCTION and it fits ok, or you can move the text box down below C++ Libraries where there's plenty of room and it makes it say boost c++ libraries under construction which is cool, but neither of the latter two options is balanced graphically.

We need to ensure the message is hard to misunderstand. So the flow of text that is natural to read is important and then of cause what it mean. It is not boost that is under construction, is it.

One other change I would make is that since they really mean, "not really part of boost yet if ever", that they should be red, to say that even though our main message is "boost" you should pay attention to this.

Yes that may be a good idea. It breaks the style though. -- Bjørn

-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Bjørn Roald Sent: Saturday, January 30, 2010 4:16 AM To: boost@lists.boost.org Subject: Re: [boost] C++ Networking Library Release 0.5

On Saturday 30 January 2010 01:57:05 am Dean Michael Berris wrote:

...

On Sat, Jan 30, 2010 at 8:44 AM, Robert Ramey <ramey@rrsd.com> wrote:

...

Would it be possible for some one to craft a logo which has the word "Proposed" plastered over the normal boost logo. This would better communicate the true intention. That this a library which is intended to become part of boost, but which hasn't been officially accepted yet.

I think boost should have guideline for this in documentation templates and guidelines and probably in the wiki. A standard set of logo designs used at various stages in a proposal life-cycle may be good, I made some proposal designs and uploaded to the vault as logo/boost_logo_alternatives.zip

http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_logo_alter natives.zip&directory=logo&

I've been toying with this idea, but yours are much better. This is excellent - especially if we can formalise the various stages of 'acceptance' into Boost. (versions as svg would also be useful). Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com

On Sat, Jan 30, 2010 at 3:35 PM, Rutger ter Borg <rutger@terborg.net> wrote:

Dean Michael Berris wrote:

...

You can find documentation about cpp-netlib over at

    http://cpp-netlib.github.com/

Thanks in advance everyone and I hope this helps!

Interesting. How does this relate, if at all, to Urdl?

http://think-async.com/Urdl/doc/html/index.html

From what I can see, Urdl is mainly a library for interacting with resources over HTTP and has an optional built (linkable) library implementation.

cpp-netlib is purely header-only, focuses on extensibility, and is meant to implement other protocols like SMTP, FTP, among other client and server-side implementations. cpp-netlib also contains an embeddable HTTP server template. It also depends on Boost.Asio but encapsulates this detail in the implementation. I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

I have an HTTP request parser using Spirit, if you're interested. It is a bit grotty as I wrote it as my first exercise using Spirit - but it does work. http://svn.chezphil.org/libpbe/trunk/src/parse_http_request.cc . Out of interest, is the parser suitable to use as a tutorial on how to

Phil Endecott wrote: translate from RFC specs? It would be nice to build a library of reference parsers that handle assorted protocols. email is a very interesting one, since the standard (and not-standard-but-in-use) variations on sender, date and time etc are quite tricky, and I guess there is some commonality given that the RFCs tend to reference each other. (Sort of thing I'm thinking of is the comment parts embeddable in dates and the newlines etc). Thanks James

Hi Phil and James, On 31 January 2010 12:08, Phil Endecott <spam_from_boost_dev@chezphil.org>wrote:

James Mansion wrote:

...

Phil Endecott wrote:

...

I have an HTTP request parser using Spirit, if you're interested. It is a bit grotty as I wrote it as my first exercise using Spirit - but it does work. http://svn.chezphil.org/libpbe/trunk/src/parse_http_request.cc .

Out of interest, is the parser suitable to use as a tutorial on how to translate from RFC specs?

You're welcome to use it in that way if you wish. Most of it was translated directly from the BNF in the RFCs.

It also makes the point that almost no-one actually does implement these things by taking the BNF, because if you do that it won't work. There is at least one bug in the HTTP BNF that is documented on an errata web page somewhere (the URL is in my source) but that has never justified a new RFC after 11 years...

It would be nice to build a library of reference parsers that handle

...

assorted protocols. email is a very interesting one, since the standard (and not-standard-but-in-use) variations on sender, date and time etc are quite tricky, and I guess there is some commonality given that the RFCs tend to reference each other. (Sort of thing I'm thinking of is the comment parts embeddable in dates and the newlines etc).

If you try to parse email headers per the BNF in the RFCs you will fail on a huge proportion of it. Somewhere I have a list of all the date formats that I have seen; it is ridiculous. I think this is a fundamental problem with text-based protocols; the "spec" is not the real spec; the real spec is the deployed implementations (see e.g. HTML parsers). Anyway, that's off-topic....

I would say that this is on-topic as it is an issue that we face in implementing cpp-netlib. Currently, the request parser in the HTTP server is taken from Boost.Asio HTTP example but I'm certain that this can be improved. Phil: thank you for your comments, I've added them to our issue tracker: http://github.com/cpp-netlib/cpp-netlib/issues If anyone would like to comment on these or add other issues, I'd encourage you to do so on our mailing list. Thanks, Glyn

Peter Petrov wrote:

First, Spirit is unsuitable for the task - it consumes all the input in one pass, and doesn't support the case when the HTTP request arrives in more than one read. The real solution is a state-machine-based parser, just like the one in the Asio HTTP example.

I'd agree with your preference for a passive state-machine based handler, and also that Ragel is an excellent tool - but surely the alternative is 'just' that the spirit parser must block waiting for more input. Either using a thread or a coroutine. James

Coroutines could work, though I doubt the complexity (e.g. using yielding iterators with Spirit) or performance will be any better than simply using a FSM-based parser.

Yesterday I tried to switch our server's custom parser to Spirit. Our custom parser is extremely fast and does 0 allocation, but I was ready to take a moderate performance hit to gain in readability and maintainability. The problem we have is that if we want to add more features to our custom commands - note, this is not a web server, this is something much more simpler - it will make the code more complex whereas in Spirit it will just be a matter of adding new rules without adding any new dependencies (we already use boost, so the library is in our build and release chain). In addition, I love the way Spirit tackles the problem. Unfortunately, I forgot I spent a certain amount of time optimizing our custom parser to be a zero-copy, zero-allocation parser (not to mention a fair deal of mpl to have basically very little code at runtime). Basically, the current parser spits out a pair of read-only pointers for each block you want to work on when with Spirit the straightforward way implies creating a string, which means in many case making a dreaded memory allocation (yes, I have a problem with this :p). Maybe MSM is more suited for that kind of tasks. I also want to mention that I'm a noob when it comes to Spirit so perhaps with more magic one could achieve results closer to our custom parser. When our version one is released, I will work more on that custom parser vs MSM vs Spirit thingy and let you know. Generally speaking I think it is worth spending some time with Spirit because writing a grammar to parse input is an order of magnitude easier to maintain than writing a custom parser. I'd also want to point out that MSM will soon land in Boost and it is a viable alternative for this kind of problems. -Edouard __________ Information from ESET NOD32 Antivirus, version of virus signature database 4826 (20100202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

On Tue, 02 Feb 2010 17:12:35 +0800, Joel de Guzman <joel@boost-consulting.com> wrote:

I'm not sure what you mean by "the straightforward way implies creating a string". String for what? The attribute? The input? Spirit does not allocate any memory. Also, AFAIK, you can avoid using strings. Perhaps be more specific?

Let's say I have an input of const char *. My input consists of a command with up to two parameters. I used Spirit to parse this command and decompose it into chunks (which means that the result of the parsing will be one enum and two "strings"). Currently it's a simple loop which returns the pointers to the chunks. Very fast (obviously).

From what I understood of Spirit, I wrote a parser which created a string when it found my chunk. On top of my head it might have looked like this

lit("command1") >> +char_[ref(my_str) = _1] >> lit("separator") >> +char_[ref(my_str2) = _1] | lit("command2) >> +alnum_[ref(my_str) = _1] This is really cool and much easier to understand than the current loop. Currently the memory allocation occurs when putting the input into the string. I now realize I can replace ref(my_str) = _1 with something that's going to build a pair of pointers based on the input which should reduce the gap between Spirit and the custom parser. But then I encountered a different problem which is that the 'grammar' cannot be read from left to right. Basically the input may contain the separator, so what I currently do is read my command, start from the right, when I reach the separator I have my second token and the rest is the first token. That can be avoided as well in offloading this part off Spirit. Then again I want to insist I'm new to Spirit and just wanted to give it a shot and see if I could quickly leverage it. It is my current conclusion that for my specific problem MSM might be best suited, but then again I just wanted to allocate one day for this mini-benchmark and all I can say is that it will take more than one day to tell, day I don't have. -Edouard

On Tue, 02 Feb 2010 20:41:12 +0800, Joel de Guzman <joel@boost-consulting.com> wrote:

Understood. Well, if you have more time and want to give it another shot, then we're here if you need help.

Thanks a lot, I really appreciate. I will definitely give it another shot after version one is released. -Edouard

...

I'm not sure what you mean by "the straightforward way implies creating a string". String for what? The attribute? The input? Spirit does not allocate any memory. Also, AFAIK, you can avoid using strings. Perhaps be more specific?

Let's say I have an input of const char *. My input consists of a command with up to two parameters. I used Spirit to parse this command and decompose it into chunks (which means that the result of the parsing will be one enum and two "strings").

Currently it's a simple loop which returns the pointers to the chunks. Very fast (obviously).

...

From what I understood of Spirit, I wrote a parser which created a string when it found my chunk. On top of my head it might have looked like this

lit("command1") >> +char_[ref(my_str) = _1] >> lit("separator") >> +char_[ref(my_str2) = _1] | lit("command2) >> +alnum_[ref(my_str) = _1]

typedef iterator_range<char const*> range_type; typedef std::pair<range_type, range_type> result_type; rule<char const*, result_type()> r = "command1" >> raw[+(!lit("separator") >> char_)] >> "separator" >> "command2" >> raw[+alnum]; Does exactly as the above except it returns two pairs of pointers to the arguments of your commands. Just call it as: char const* begin = ...; char const* end = ...; result_type rt; parse(begin, end, r, rt); allowing you to access your pairs of pointers from rt. Voila! No memory allocation at all!

This is really cool and much easier to understand than the current loop. Currently the memory allocation occurs when putting the input into the string. I now realize I can replace ref(my_str) = _1 with something that's going to build a pair of pointers based on the input which should reduce the gap between Spirit and the custom parser.

But then I encountered a different problem which is that the 'grammar' cannot be read from left to right. Basically the input may contain the separator, so what I currently do is read my command, start from the right, when I reach the separator I have my second token and the rest is the first token. That can be avoided as well in offloading this part off Spirit.

I think this is solved by the above rule. HTH Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

...

...

lit("command1") >> +char_[ref(my_str) = _1] >> lit("separator") >> +char_[ref(my_str2) = _1] | lit("command2) >> +alnum_[ref(my_str) = _1]

typedef iterator_range<char const*> range_type; typedef std::pair<range_type, range_type> result_type; rule<char const*, result_type()> r = "command1" >> raw[+(!lit("separator") >> char_)] >> "separator"

...

"command2" >> raw[+alnum];

Does exactly as the above except it returns two pairs of pointers to the arguments of your commands. Just call it as:

char const* begin = ...; char const* end = ...; result_type rt; parse(begin, end, r, rt);

allowing you to access your pairs of pointers from rt. Voila! No memory allocation at all!

Awesome! Well now I *have to* test this. ;) - in the long run having a real parser will do us good.

Then I have an additional question, if you mind, as I said the second problem we have is that my command parameter may contain the separator, we get around this by parsing right to left. This is not something we can do much about it, unless we encode all the commands parameters which is a thing we cannot realistically do.

Let me give you an example:

command1/aaa/bbb/ccc/ddd

We currently extract "aaa/bbb/ccc" and "ddd".

The way I want to do this in Spirit is extract "aaa/bbb/ccc/ddd" and manually extract "ddd" from it. The other possibility is to extract "aaa", "bbb", "ccc" and "ddd" and since I have a pair of pointers just merge the pair "aaa" => "ccc".

What would be a more sensible approach to this?

Well, it all depends (as usual) on a) whether you know how many separators you have overall in this case you can build the grammar accordingly. b) whether you already know where the end of the string is, or otherwise you have to scan the string once to find the end anyways. If you don't know the string length upfront (you have to scan it once to find eos), then I'd remember the position of the last separator along the way and parse the two parts separately. If you do know the eos without scanning, you could do two parse steps as well: using reverse_iterators rbegin/rend to recognize command2 from the end which gives you the last separator and then using the begin/lastsep iterators to recognize command 1. HTH Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

edouard@fausse.info wrote:

On Tue, 2 Feb 2010 07:13:27 -0600, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> wrote:

...

typedef iterator_range<char const*> range_type; typedef std::pair<range_type, range_type> result_type; rule<char const*, result_type()> r = "command1" >> raw[+(!lit("separator") >> char_)] >>

"separator"

...

...

"command2" >> raw[+alnum];

Then I have an additional question, if you mind, as I said the second problem we have is that my command parameter may contain the separator, we get around this by parsing right to left. This is not something we can do much about it, unless we encode all the commands parameters which is a thing we cannot realistically do.

Let me give you an example:

command1/aaa/bbb/ccc/ddd

We currently extract "aaa/bbb/ccc" and "ddd".

The way I want to do this in Spirit is extract "aaa/bbb/ccc/ddd" and manually extract "ddd" from it. The other possibility is to extract "aaa", "bbb", "ccc" and "ddd" and since I have a pair of pointers just merge the pair "aaa" => "ccc".

If those delimiters appear as shown, why not parse for them? component = +(~ch_p('/')) command1 = "command1/" >> component // aaa >> '/' >> component // bbb >> '/' >> component // ccc >> '/' >> component // ddd I've not attached any semantic actions, but that should be a fairly easy application of what Hartmut showed already. You'd only need the start of what matches the first component (sub)rule and the end of what matches the third one, to span "aaa/bbb/ccc," of course. Another approach is to allow for the delimiter in the middle, but not the end, though you need to match EOL or something to signal the end of the command: "command1/" >> +(alpha_p | '/') >> '/' >> +alpha_p >> eol_p _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

Peter Petrov wrote:

Agreed threads are alternative, but only for small servers without high scalability requirements (e.g. tens of thousands simultaneous HTTP keep-alive connections). The thread-per-connection model is outdated and in 2010 it's not a good idea to start a framework which relies on it.

Well, I'd actually argue the contrary now that we have 64 bit systems and the old issues of running out of VM addresses for stacks is gone. Having said that I too prefer async IO - but I'm really not sure many applications need more than 10k connections, and while I'd have baulked at that number of threads, I suspect that all the major server platforms can handle that many these days.

Coroutines could work, though I doubt the complexity (e.g. using yielding iterators with Spirit) or performance will be any better than simply using a FSM-based parser.

Well, I'd prefer an FSM based parser, but Spirit sucks for that, since its a pull parser and you are only able to get away with it by making assumptions about receiving a 'whole message' before starting the parse. Which implies either an assumption about some alignment of read with content delimiters, or that you pre-scan the content to find the delimiter - and process every byte twice. A well executed push parser need not do that, and ragel or re2c feeding lemon is the best approach I know of. I haven't tried the ragel author's parser. James

On Feb 1, 2010, at 1:49 PM, Phil Endecott wrote:

Hi In the case of HTTP POST and PUT requests, on the other hand, the body (but not the header) can be large, and parsing it incrementally as it arrives probably is necessary. I noticed a BoostCon paper about a MIME parser (Marshall?) - this would definitely benefit from working incrementally in many applications.

Yeah; currently, it assumes that you've got the whole structure. I'm going to have to think about incremental parsing. Anyone who wants a copy of the (current state of the) parser, ping me off-list. I have to write some docs before it I make it generally available. I'm quite happy to take suggestions. -- Marshall

On Tue, Feb 2, 2010 at 12:37 AM, Peter Petrov <ppetrov@ppetrov.com> wrote:

Your assumption about the single-TCP-packet HTTP requests however is wrong. I made the mistake of assuming the same thing initially as well. But at least Opera has the habit of sending requests across packet boundaries far too often. In my case though, most requests travel on long-lived HTTP 1.1 keep-alive connections, which might be a trigger for this.

Substitute "request" with "request header" in the above paragraph. I should read my posts before sending in the future :)

Michael Caisse wrote:

While not wanting to be self-serving .... I will be discussing how to use Spirit and Asio together at BoostCon in presentations on Spirit and Asio. I have been developing a utility that works well for many of my applications that require asynchronous messaging. I have also utilized it with embedded HTTP servers.

While the source works well and is shipping with a few client projects, it is rough in Boost terms and is going through refinements for a May introduction.

I would like to combine Spirit and Asio as well -- what parts of both libraries does your utility tie together? Handling partial reads? Would it be possible to take a peek at the rough version? Thanks, Kind regards, Rutger

Michael Caisse wrote:

Rutger -

The utility ties together Qi rules/grammars with asynchronous reads and Karma rules/grammars with asynchronous writes. There is a policy that handles behavior during partial reads.

I'll try to bundle something up sooner than later... perhaps this weekend.

I'd be interested to see if and how you achieved a single pass parser, is this the case? Does it continue where it left off in case of partial reads? Thanks. Rutger

Hi Vicente, On 30 January 2010 16:08, vicente.botet <vicente.botet@wanadoo.fr> wrote:

----- Original Message ----- From: "Dean Michael Berris" <mikhailberis@gmail.com> To: <boost@lists.boost.org> Sent: Saturday, January 30, 2010 12:33 AM Subject: [boost] C++ Networking Library Release 0.5

...

Good day everyone, and I apologize in advance for the shameless plug. That said though, I'd like to announce the availability of version 0.5 of the C++ Network Library (cpp-netlib) on both Github and Sourceforge.

For those interested in trying out a header-only being-developed-for-boost-inclusion networking library collection, you

...

You can find documentation about cpp-netlib over at

http://cpp-netlib.github.com/

Thanks in advance everyone and I hope this helps!

Hi,

looking at the Message Concept let me think that the goal of library is to help on networking application for text based protocols. Is this the scope of the library? Can the library be used on binary based protocols?

Normally this should be the case. The Message concept is used to define the storage criteria and doesn't specify whether that should be text or binary, though cpp-netlib will implement mostly text-based protocols. HTH, Glyn