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

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

Hi Peter!

On 21 May 2007 06:22:27 +0200, Peter Simons <si...@cr...> wrote:
>
> Yes, for an Uri class that's perfectly reasonable, but for other
> classes things are not that obvious. The rfc2822 parsers, for
> example, are, well, parsers. They will typically be applied to
> data that comes from the network, but the need to parse an e-mail
> address can just as well arise in a spreadsheet program. Adding
> those parsers into a boost/network/rfc2822/ hierarchy does make
> sense to a degree, but it doesn't feel like the natural choice --
> particularly considering the fact that those parsers will never
> depend on anything else in the network hierarchy.
>

I agree that boost/network/rfc2822 doesn't feel natural. Would you
have a different name from rfc2822 which might make more sense and be
more descriptive? It might also even make sense that we can put it in
boost/network/smtp/parser/ and have a boost/network/smtp/parsers.hpp
file (just in case I understand that the parsers are for SMTP
parsing).

> I still can't quite imagine what the scope of this whole endeavor
> is. Right now, I have a hard time seeing how my code fits in.
>

Okay, let me try and do a bird's eye view:

We have a message class, which every network protocol implementation
will use (meaning, create/return/manipulate/process). Of the network
protocol implementations, there will be parsers which will accept
string input and validate then generate message objects. These parsers
will generally be based on Boost.Spirit.

That being said, protocol implementations for SMTP processing will
definitely be used to generate message objects which the SMTP handlers
will use to perform the necessary actions. For example, for mail
sending the parsers will have to parse string responses from the SMTP
servers. Another example is for SMTP servers where incoming text
messages will be processed with a parser to generate the appropriate
message object, which then can be passed on to application specific
handlers. A POP client will also benefit from parsers to create
message objects on a per-email basis.

I hope the above descriptions/narrative makes things clearer... I
admit am having a hard time writing down these things that are pretty
much still all in my head. I will do what I can though to be able to
document all this before and during the development process.

>
>  >> What are the components we anticipate to have in cpp-netlib?
>  >
>  > Definitely a URI class would be a good idea.
>
> Right, an URI class would be great to have.
>
> Are there any other components we anticipate or would like to
> implement? What is the goal for cpp-netlib? When it's all done
> and accepted into boost, what does it contain?
>

One question at a time. ;-)

Components we anticipate are (aside from the message class):

  - asynchronous name resolver
  - "synchronous timeout reader/writer"
  - protocol implementations (of course)
  - server templates (for PBCP and CRTP servers)

The goal for cpp-netlib is to:

 * provide a high-quality, generic, extensible collection of
network-related routines and popular protocol implementations using
the C++ programming language
 * become the Boost.Network library
 * enable generic network protocol implementations
 * lower the barrier to entry for network-aware C++ applications

When it's gotten into Boost, it should contain at least the following:

 * Common message type
 * Transformations/Manipulations for the common message type instances
 * Minimal HTTP implementation

If we can even make an SMTP implementation using the parsers you've
written, then we could include that as well in the list above.

> I'm sorry for bringing up those very general questions instead of
> committing code, but it feels important to develop some sort of
> shared vision. I have my code in a publicly available repository
> already; so it doesn't feel like I'm gaining a lot by checking it
> into this repository instead. I would do so because I'd hope that
> the code might become part of a team effort. At the moment, I
> can't quite say where exactly that team effort is headed. It
> would be nice to develop that notion.
>

I'm open to suggestions as well. :) I'm also thankful that you bring
up these questions early, so that we can go discuss the direction at
this point, then be able to plan for the concrete actions that we'd
like to take.

I'd really like to know your thoughts on the things I've written above.

I hope this makes things clear to some extent. Please ask away and
suggest away about any matter regarding the development process and or
direction of the project.

(I'm pretty new at this open source development thing as well, and I
do have some trouble writing down ideas so please bear with me on
this... I'll try my best to articulate in terms of
English/HumanLanguage what I think -- and if I can't I'll write code
instead. ;) ).

> Best regards,
> Peter
>

Thanks again Peter!

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