Re: [boost] Is Boost interested in the Boost-based Base64 library

Subject: Re: [boost] Is Boost interested in the Boost-based Base64 library
From: Anthony Foiani (tkil_at_[hidden])
Date: 2011-06-11 09:56:12

"Robert Ramey" <ramey_at_[hidden]> writes:

[snipped example wrapping detailed, generic code to provide "obvious"
if less flexible interface]

> Which I don't really see as a bad idea in and of itself.  But I wonder about 
> other aspects?
>
> a) where in the directory/namespace would this be? boost,
>    boost/utility, or?

Maybe add a "Boost.Cookbook", showing mere mortal C++ programmers how
to best use the deeper aspects of Boost?

It could even be advertised as "non-normative", in a sense, so that it
wouldn't hold up a release.

> b) would it include all the boost machinery besides code? 
>    documentation, formal review, tests etc?

If we allocated a cookbook / samples directory, we could use "silos"
to apply the formal process to individual files/functions:

  doc/base64.txt
  src/base64.hpp
  test/base64_test.cpp

This would be completely independent of someone taking, e.g., one of
the TCP servers out of the ASIO docs and making a sample out of it:

  doc/tcp_server.txt
  src/tcp_server.hpp
  test/tcp_server_test.hpp

I just caught up on a week or two of posts to boost-devel, and I
recall there was at least one other instance of someone suggesting a
tiny snippit of code for inclusion into boost, and others replying
[essentially] that there's too much overhead to bother adding 6 lines
somewhere.

> c) All this for one small special purpose function?

There are many other useful small snippits that are currently strewn
across the documentation for various libraries.  Maybe centralizing
them in one place (again, as "cookbook" or "here's how the boost
experts /use/ boost, as opposed to when they're writing boost") would
be helpful.

I'm particularly reminded of a quote from Scott Meyer's _Effective STL_:

  "One programmer's vision of expressive purity is another programmer's
  demonic missive from Hell."

> d) How is a user going to find this pair of functions in the boost 
>    libraries.

A cookbook with an index, especially with keywords, would be nice.

(Speaking of which, is there a single index that covers all the boost
libs in a single document?)

> e) As soon as someone puts this in, imediately some else will ask -
>    great but it needs a parameter to so I can change the line
>    width. Then someone asks for someother tweak.  This is the result
>    of making a "simple solution". It's easy enough to make a simple
>    solution - it's very hard to keep it simple.

Ah, but the cookbook approach would allow for a better response: we've
shown you how to do the simple, straightforward thing using these
powerful constructs; if you want to change something, take this code
and adapt it to your needs, or use the more powerful tools directly.

> This is the reasoning behind my suggestion that for something like
> this one should be prepared to think bigger. In my view value of
> something like this (it DOES have value) isn't justified by the cost
> of getting it into boost. My advice - think bigger.

Does a cookbook seem a reasonable way to think bigger?

> I realize that the overhead of all this isn't your fault, but it
> still exists. I don't see boost as having the infrasture to handle
> an army of small (special purpose) functions such as this.

It might be that creating such a nook would allow for quite a few
contributions, precisely because there's such a high hurdle to
overcome for a normal library. I'd guess that everyone on this list
has a handful of "helper functions" that they'd be happy to submit if
it only took an hour of their time, but can't afford to make fully
generic and fleshed out and then wait 6 months for review.

Just an idea.

Best regards,
Tony