Re: [cpp-netlib-devel] Some code already up in subversion

[Dean M. B. <mik...@gm...>]

Hi Peter!

On 20 May 2007 21:27:15 +0200, Peter Simons <si...@cr...> wrote:
> Hi guys,
>
> it took a while to remember my sf.net password, but in the end I
> managed to commit. :-)
>

Great! I'll check out your changes soon as I can. :)

> I have a question. In the boost-sandbox repository, everyone is
> encouraged to add a top-level directory per project. An imaginary
> foo library is organized in SVN as follows:
>
>   foo / boost / foo.hpp
>   foo / boost / foo / ...
>   foo / libs  / foo / src  / ...
>   foo / libs  / foo / doc  / ...
>   foo / libs  / foo / test / ...
>
> How would we like to handle that? What is the granularity we aim
> for in this project? Let's say we come up with a very good class
> for representing URIs. Do we try to make that URI library a
> stand-alone component (that can be submitted to boost on its
> own), or is URI something that's tightly integrated into
> cpp-netlib?
>

A suggestion would be to have that class under the boost/network/
directory. This would yield something like a 'boost/network/uri.hpp'
header which can be used on its own.

cpp-netlib supposedly follows the above structure, replacing 'trunk'
with something like 'network' so the structure looks like

    network / boost / network
    network / libs / network

> Tight integration often leads to more efficient source code
> because chances for re-use are higher. If things are integrated
> too tightly, however, it is hard to use any one component of the
> library without using everything else too.
>

Agreed.

> What are the components we anticipate to have in cpp-netlib? A
> general purpose class for things that look like an "Internet
> Message" is one of topics we need to address, but what else would
> we like to see in Boost?
>

Definitely a URI class would be a good idea, preferrably something
that is convertible to a std::string by default. We can even use the
same approach we have for creating message objects with directives and
operator overloads to make the usage be a bit more expressive.

> Best regards,
> Peter
>

Thanks Peter!

I hope the above explanation makes sense. :)

-- 
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459