Ei Glyn!
On 7/7/07, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean, good to hear from you!
>
It feels great to be back in C++ development... I can't imagine how
developers who've done the switch from problem solvers to
whip-crackers are managing... ;-) I just hope I can stay in this C++
hacking mode a bit more. :)
> On 07/07/07, Dean Michael Berris <mik...@gm...> wrote:
> > I'd appreciate it if anyone can check in GCC whether the latest in the
> > SVN repo will build and pass the tests correctly.
>
> I can confirm that the tests pass on Linux with GCC (4.1.2) and also with
> the Intel compiler (9.1).
>
Nice! Thanks Glyn!
> > Thanks in advance! Now I can move forward to implementing the common
> > transformations for network messages.
> >
> > How's everybody doing?
>
> Fine. I'm glad to hear that some progress has been made here, I was a bit
> worried that it has kind of fizzled out. What according to you is the next
> stage of development, and how can we get involved?
> Glyn
>
The next stage of development would be to build around this simple
message type, and implement what's immediately necessary to get an
HTTP client out the door. There are a few things which I would like to
set as guidelines for the forward progress of the project:
* The style should be consistent. If you check the code, everything
-- and I mean everything -- is a template (either a template method, a
template class, a nested template class, etc). The rationale for this
is that we'd like to keep external dependencies only limited to the
Boost C++ Library (latest in CVS or SVN when that move happens) and
the STL, and as much as possible not much else.
* Use TMP (Template MetaProgramming) whenever possible to leverage on
earlier work and static properties of C++.
* Implement common transformations from one message type to another
using free functions and non-mutable copy semantics (first). That
means let's use the message class as much as possible, make copies
instead of hold references wherever possible to make thread-safe
programming a bit easier, and put in as much extensibility as we can.
Example would be to implement a boost::network::http::request type
which already has default information in the headers and can be
copy-constructed from an existing message instance -- and specific
transformations just for http-request/response messages. I can go into
detail if someone would like to take on this challenge sooner than
later. ;)
If anybody can point out other nit-picks (like my use and dependence
on std::string) and perhaps check in patches to the code without
having to change the tests, that would be greatly appreciated. If
there's anything else, like additional functionality you'd like to put
in, please check in both the unit test which shows the interface and
how it's intended to be used, and the implementation.
I would like to encourage branching if you think you'll be checking in
too many things and breaking a lot of already existing code. You can
use a prefix (like in my case dmcb) as the branch name if and when you
do decide to branch off the main trunk.
I would also like to start the discussion about what other features
you'd like to see the message type and eventually the HTTP client
library support for the first release of the library. Setting feature
milestones (similar to what the RATIONALE document already contains)
would be a good idea for us to gauge when we can do a release and how
much effort we still need to do to come up with something "acceptable"
to the community.
Please let me know your thoughts. :)
Have a great weekend everyone!
--
Dean Michael C. Berris
http://cplusplus-soup.blogspot.com/
mikhailberis AT gmail DOT com
+63 928 7291459
|
