cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] Header-only HTTP Server Coming

[Glyn M. <gly...@gm...>]

Hi Dean,

2009/11/29 Dean Michael Berris <mik...@gm...>

> Hi Guys,
>
> I'm doing some consulting work right now which allowed me to implement
> an HTTP Server template which thankfully I've gotten a go-signal to
> opensource under the Boost Software License.
>

Cool.

This is not the same HTTP server template that I developed in
> Friendster -- I'm still waiting for them to release that as open
> source -- and this implementation heavily borrows from the Boost.Asio
> server 3 example (although is header only).
>

Are these two different implementations of the same thing or do you intend
to do some merge on the differences?  I'm looking forward to seeing this.


>
> Glyn, how are we doing with releasing version 0.4? I'll request a
> merge from my urllib-dean branch into integration_0_4 so that we can
> finally merge back to trunk and release version 0.4 that uses
> Boost.Spirit 2.1.
>

Please feel free to do the merge.  John sent me a off list saying that he
didn't want to contribute any longer and, since his branch has diverged a
long way, I don't expect we'll be able to reintegrate it.

For 0.4 I wanted:

A URI package with unit tests
The HTTP client using the new URI (which you say you just completed)
Better docs
Better examples

I would therefore say we're pretty close, short of the documentation.  I'm
afraid I can only commit a small amount of time in the next couple of weeks,
but I will try and make progress with the documentation so as not to hold up
the release.  (Also, please feel free to pass comment on the current docs in
integration_0_4).

I take a holiday on the 17th Dec so I expect to release before then.
G

Re: [cpp-netlib-devel] Integrated URI into http::request

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

On Mon, Nov 30, 2009 at 4:14 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> 2009/11/29 Dean Michael Berris <mik...@gm...>
>>
>> Hi Guys,
>>
>> I've just committed revision 203 which integrates the URI
>> implementation into http::request. Now the classic spirit parser in
>> http::request has been removed and delegated to the URI object
>> internal to every http::request.
>>
>> All tests pass and the changes were minimal.
>
> That's great! This a box checked and means we should be close to a release.

Do you remember the other checklist items?

The only thing I remember are: uri implementation and https (?). Am I
missing anything else?

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Integrated URI into http::request

[Glyn M. <gly...@gm...>]

Hi Dean,

2009/11/29 Dean Michael Berris <mik...@gm...>

> Hi Guys,
>
> I've just committed revision 203 which integrates the URI
> implementation into http::request. Now the classic spirit parser in
> http::request has been removed and delegated to the URI object
> internal to every http::request.
>
> All tests pass and the changes were minimal.
>

That's great! This a box checked and means we should be close to a release.
Thanks,
Glyn

[cpp-netlib-devel] Header-only HTTP Server Coming

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

Hi Guys,

I'm doing some consulting work right now which allowed me to implement
an HTTP Server template which thankfully I've gotten a go-signal to
opensource under the Boost Software License.

This is not the same HTTP server template that I developed in
Friendster -- I'm still waiting for them to release that as open
source -- and this implementation heavily borrows from the Boost.Asio
server 3 example (although is header only).

Glyn, how are we doing with releasing version 0.4? I'll request a
merge from my urllib-dean branch into integration_0_4 so that we can
finally merge back to trunk and release version 0.4 that uses
Boost.Spirit 2.1.

TIA and HTH

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

[cpp-netlib-devel] Integrated URI into http::request

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

Hi Guys,

I've just committed revision 203 which integrates the URI
implementation into http::request. Now the classic spirit parser in
http::request has been removed and delegated to the URI object
internal to every http::request.

All tests pass and the changes were minimal.

Thanks and I hope this helps.

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

[cpp-netlib-devel] More URI Examples and Tests?

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

Hi Everyone,

Does anybody have time to spare to help write more URI tests to make
sure the implementation is already sound? I'm particularly interested
in "negative" tests, where we look for invalid HTTP URIs that the
library reports to be valid.

Please feel free to commit to the urllib-dean branch or send in
patches if you don't have commit rights to the repository yet.

Thanks everyone and I hope to see more tests soon! :)

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Updated 0.4 integration branch

[Glyn M. <gly...@gm...>]

Hi Dean,  Thanks for the quick response.

2009/11/18 Dean Michael Berris <mik...@gm...>

> On Wed, Nov 18, 2009 at 8:53 PM, Glyn Matthews <gly...@gm...>
> wrote:
> > Hi Dean,
> >
> > 2009/11/17 Dean Michael Berris <mik...@gm...>
> >>
> >> The reasoning for this is so that we can have different interfaces for
> >> the different specializations of basic_message. Although we might
> >> probably be able to get away with a Message concept which is opaque
> >> and can be checked/enforced by BCCL, my concern for that would be the
> >> lack of "specialization" for writing generic algorithms that might be
> >> able to do tag dispatching. For instance:
> >>
> >>  template <class Tag>
> >>  void foo(basic_message<Tag> const & msg) {
> >>    bar(msg, Tag()); // use tag dispatching
> >>  }
> >>
> >> This also allows us to specialize some operations on basic_messages:
> >>
> >>  template <class Tag, class Transformation>
> >>  basic_message<Tag> transform(basic_message<Tag> const & msg,
> >> transformation<Transformation> f) {
> >>    return f(msg);
> >>  }
> >>
> >> Although this might work with BCCL using opaque types, it's worth a
> >> shot. Again let me look back at cleaning up the message abstraction
> >> and algorithms at a later time.
> >
> > It's still not clear.  I'll try and describe my problem in more detail on
> > the wiki, but it's difficult for me to see the advantages without some
> > concrete examples.
> >
>
> Alright. I'll wait for the page. One last try:
>
> Let's say I want to implement a function 'swap' that can be pulled via
> ADL. I would typically write it like this:
>
>
> namespace boost { namespace network {
>
>  template <class Tag>
>  inline
>  void swap(basic_message<Tag> & l, basic_message<Tag> & r) {
>    l.swap(r);
>  }
>
> } }
>
> Without this, I'm going to be stuck with a globally defined function
> 'swap' which I cannot specialize or narrow down to types of messages.
>
> Does this help?
>

Nope, cos that's not the question I wanted to ask :)  I'll try and
reformulate it again when I'm not as distracted.


>
> >
> >>
> >> > 4. I don't like the name, tags::default_.  I added
> tags::default_string
> >> > and
> >> > tags::default_wstring, and, while they're more descriptive, I think
> they
> >> > can
> >> > be improved.
> >>
> >> The intention in my brain for tags::default_ was not just for what
> >> kind of strings to use, but also for default implementations for
> >> example of the HTTP client and the basic_message template. The
> >> default_ tag was meant to be the default implementation for anything
> >> that was being shipped with the library -- and traits were dispatched
> >> according to that tag. This allows for using compile-time flags to
> >> switch the default typedef for boost::network::message from
> >> `boost::network::basic_message<tags::default_>` to
> >> `boost::network::basic_message<tags::special>` or something to that
> >> effect.
> >>
> >
> > My problem is with the name not the idea, it's ugly (as an aside, as a
> C++
> > programmer I'm often very frustrated that names I want to use such as
> > `default` and `register` are reserved).  The suggestions I gave just
> weren't
> > that much better.  Can we do something like
> > `boost::network::basic_message<>` to indicate the default?  Boost.Random
> > does something similar to this.
> >
>
> Sure, but what would you name the default tag? Only reason it's
> tags::default_ is because default is a keyword. :D
>
> Even if we have:
>
>  typedef basic_message<> message;
>
> What would you call the tag name that's default in the basic_message
> implementation? And what tag do you dispatch on? :D
>

Yeah, I see.



> >>
> >> > 6. The implementation of http::message and http::message uses
> >> > std::string
> >> >
> >>
> >> Yeah, I should change that really. File Trac tickets? :) I don't
> >> receive emails though, is there something that I should do special to
> >> get alerts on new tickets filed and assigned to me?
> >
> > Oh I don't know.  I get e-mail alerts but I thought that was set up by
> > default.
> >
>
> Let me see if I need to tweak anything in my settings. Have there been
> any filed tickets regarding this assigned to me yet?
>

I don't think so.

>
> >>
> >> > Please try and run the tests and let me know if there are any other
> >> > issues.
> >> > Dean and John, perhaps you could be able to see if the updates work
> with
> >> > what you're both trying to do.
> >> >
> >>
> >> Is the branch cut from trunk, or was it cut from somewhere else? I'll
> >> try to merge your changes into my branch first, then come up with a
> >> patch set or try to merge back the stabilized version into the
> >> integration branch.
> >
> > Cut from trunk.  And I merged your changes from urllib-dean, so merging
> them
> > back should be trivial.
> >
>
> Aha! Cool. :) Thanks for doing this. I'll look into stabilizing and
> fixing some URI related things with HTTP as I go along. I saw this btw
> using GitG and visualized the whole tree -- we should definitely prune
> some branches when we move to git after 0.4 goes out.
>
>
>
Good :)
Thanks again,
G

Re: [cpp-netlib-devel] Updated 0.4 integration branch

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

On Wed, Nov 18, 2009 at 8:53 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> 2009/11/17 Dean Michael Berris <mik...@gm...>
>>
>> The reasoning for this is so that we can have different interfaces for
>> the different specializations of basic_message. Although we might
>> probably be able to get away with a Message concept which is opaque
>> and can be checked/enforced by BCCL, my concern for that would be the
>> lack of "specialization" for writing generic algorithms that might be
>> able to do tag dispatching. For instance:
>>
>>  template <class Tag>
>>  void foo(basic_message<Tag> const & msg) {
>>    bar(msg, Tag()); // use tag dispatching
>>  }
>>
>> This also allows us to specialize some operations on basic_messages:
>>
>>  template <class Tag, class Transformation>
>>  basic_message<Tag> transform(basic_message<Tag> const & msg,
>> transformation<Transformation> f) {
>>    return f(msg);
>>  }
>>
>> Although this might work with BCCL using opaque types, it's worth a
>> shot. Again let me look back at cleaning up the message abstraction
>> and algorithms at a later time.
>
> It's still not clear.  I'll try and describe my problem in more detail on
> the wiki, but it's difficult for me to see the advantages without some
> concrete examples.
>

Alright. I'll wait for the page. One last try:

Let's say I want to implement a function 'swap' that can be pulled via
ADL. I would typically write it like this:


namespace boost { namespace network {

  template <class Tag>
  inline
  void swap(basic_message<Tag> & l, basic_message<Tag> & r) {
    l.swap(r);
  }

} }

Without this, I'm going to be stuck with a globally defined function
'swap' which I cannot specialize or narrow down to types of messages.

Does this help?

>
>>
>> > 4. I don't like the name, tags::default_.  I added tags::default_string
>> > and
>> > tags::default_wstring, and, while they're more descriptive, I think they
>> > can
>> > be improved.
>>
>> The intention in my brain for tags::default_ was not just for what
>> kind of strings to use, but also for default implementations for
>> example of the HTTP client and the basic_message template. The
>> default_ tag was meant to be the default implementation for anything
>> that was being shipped with the library -- and traits were dispatched
>> according to that tag. This allows for using compile-time flags to
>> switch the default typedef for boost::network::message from
>> `boost::network::basic_message<tags::default_>` to
>> `boost::network::basic_message<tags::special>` or something to that
>> effect.
>>
>
> My problem is with the name not the idea, it's ugly (as an aside, as a C++
> programmer I'm often very frustrated that names I want to use such as
> `default` and `register` are reserved).  The suggestions I gave just weren't
> that much better.  Can we do something like
> `boost::network::basic_message<>` to indicate the default?  Boost.Random
> does something similar to this.
>

Sure, but what would you name the default tag? Only reason it's
tags::default_ is because default is a keyword. :D

Even if we have:

  typedef basic_message<> message;

What would you call the tag name that's default in the basic_message
implementation? And what tag do you dispatch on? :D

>>
>> > 5. Internally, we sometimes use namespace impl and sometimes namespace
>> > detail.  We should be more consistent and choose one.
>>
>> I think personally there's a distinction, but I won't fight for impl.
>> In my mind impl:: is supposed to be just for implementations, while
>> detail:: can also implement helpers and utility classes, etc.;
>> detail::impl:: might make sense but then that would be too much
>> nesting even for me. ;)
>>
>> I like detail and it follows the boost tradition.
>
> In either case, I understand both to not be a part of the public interface.
>

Right. But to be Boost friendly I think we should move to just detail.
I'll look around and see if I can move those without too much trouble.
;)

>>
>> > 6. The implementation of http::message and http::message uses
>> > std::string
>> >
>>
>> Yeah, I should change that really. File Trac tickets? :) I don't
>> receive emails though, is there something that I should do special to
>> get alerts on new tickets filed and assigned to me?
>
> Oh I don't know.  I get e-mail alerts but I thought that was set up by
> default.
>

Let me see if I need to tweak anything in my settings. Have there been
any filed tickets regarding this assigned to me yet?

>>
>> > Please try and run the tests and let me know if there are any other
>> > issues.
>> > Dean and John, perhaps you could be able to see if the updates work with
>> > what you're both trying to do.
>> >
>>
>> Is the branch cut from trunk, or was it cut from somewhere else? I'll
>> try to merge your changes into my branch first, then come up with a
>> patch set or try to merge back the stabilized version into the
>> integration branch.
>
> Cut from trunk.  And I merged your changes from urllib-dean, so merging them
> back should be trivial.
>

Aha! Cool. :) Thanks for doing this. I'll look into stabilizing and
fixing some URI related things with HTTP as I go along. I saw this btw
using GitG and visualized the whole tree -- we should definitely prune
some branches when we move to git after 0.4 goes out.

>>
>> Please expect something within the next couple of days.
>>
> Cool.  I won't be able to do much until the weekend.

Alright, thanks for responding! :)

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Updated 0.4 integration branch

[Glyn M. <gly...@gm...>]

Hi John,

2009/11/17 John P. Feltz <jf...@ov...>

>
> Glyn Matthews wrote:
> > 1. boost::network::uri::uri and boost::network::uri::http::uri have a
> > redundant namespace.  I understand that the directives maybe shouldn't be
> in
> > boost::network, but a different named namespace might be better so that
> we
> > could have boost::network::uri and boost::network::http::uri.
> >
> I think that directives which perform requirements of the uri API should
> be within a boost::network::uri namespace.  If it handles something
> specific to http uri -though not necessarily at exactly
> boost::network::uri::http-  either the associated tag should be within
> ::http, or the function or class which handles http specific things
> should be. So in short there is no easy answer, it depends on things
> like cross cutting concerns, and what boost::network::uri means ( I'll
> put what I've discussed here in the design spec for revision).
>
>
Right.  I'm struggling to come up with an alternative name that would allow
`boost::network::uri` as a class name.  Also, if we continue with
`boost::network::uri` as a namespace, I think protocol specific stuff should
be in namespace `boost::network::{protocol}`, so the HTTP URI directives
should be in `boost::network::http::uri`. :)
 G

Re: [cpp-netlib-devel] Updated 0.4 integration branch

[Glyn M. <gly...@gm...>]

Hi Dean,

2009/11/17 Dean Michael Berris <mik...@gm...>

>
> > 3. I need clarification as to why there should be tags to identify
> different
> > protocols.  I understand the need to specialize templates for strings and
> > header_containers but I can't see why we have, e.g.
> > boost::network::http::message_tags to specialize
> > boost::network::http::basic_message as we do now.  this means we have to
> > provide traits for struct string<http::message_tags> as well as
> > string<tags::default_> which are in fact going to be identical.
>
> The reasoning for this is so that we can have different interfaces for
> the different specializations of basic_message. Although we might
> probably be able to get away with a Message concept which is opaque
> and can be checked/enforced by BCCL, my concern for that would be the
> lack of "specialization" for writing generic algorithms that might be
> able to do tag dispatching. For instance:
>
>  template <class Tag>
>  void foo(basic_message<Tag> const & msg) {
>    bar(msg, Tag()); // use tag dispatching
>  }
>
> This also allows us to specialize some operations on basic_messages:
>
>  template <class Tag, class Transformation>
>  basic_message<Tag> transform(basic_message<Tag> const & msg,
> transformation<Transformation> f) {
>    return f(msg);
>  }
>
> Although this might work with BCCL using opaque types, it's worth a
> shot. Again let me look back at cleaning up the message abstraction
> and algorithms at a later time.
>

It's still not clear.  I'll try and describe my problem in more detail on
the wiki, but it's difficult for me to see the advantages without some
concrete examples.



>
> > 4. I don't like the name, tags::default_.  I added tags::default_string
> and
> > tags::default_wstring, and, while they're more descriptive, I think they
> can
> > be improved.
>
> The intention in my brain for tags::default_ was not just for what
> kind of strings to use, but also for default implementations for
> example of the HTTP client and the basic_message template. The
> default_ tag was meant to be the default implementation for anything
> that was being shipped with the library -- and traits were dispatched
> according to that tag. This allows for using compile-time flags to
> switch the default typedef for boost::network::message from
> `boost::network::basic_message<tags::default_>` to
> `boost::network::basic_message<tags::special>` or something to that
> effect.
>
>
My problem is with the name not the idea, it's ugly (as an aside, as a C++
programmer I'm often very frustrated that names I want to use such as
`default` and `register` are reserved).  The suggestions I gave just weren't
that much better.  Can we do something like
`boost::network::basic_message<>` to indicate the default?  Boost.Random
does something similar to this.


> > 5. Internally, we sometimes use namespace impl and sometimes namespace
> > detail.  We should be more consistent and choose one.
>
> I think personally there's a distinction, but I won't fight for impl.
> In my mind impl:: is supposed to be just for implementations, while
> detail:: can also implement helpers and utility classes, etc.;
> detail::impl:: might make sense but then that would be too much
> nesting even for me. ;)
>
> I like detail and it follows the boost tradition.
>

In either case, I understand both to not be a part of the public interface.


>
> > 6. The implementation of http::message and http::message uses std::string
> >
>
> Yeah, I should change that really. File Trac tickets? :) I don't
> receive emails though, is there something that I should do special to
> get alerts on new tickets filed and assigned to me?
>

Oh I don't know.  I get e-mail alerts but I thought that was set up by
default.


>
> > Please try and run the tests and let me know if there are any other
> issues.
> > Dean and John, perhaps you could be able to see if the updates work with
> > what you're both trying to do.
> >
>
> Is the branch cut from trunk, or was it cut from somewhere else? I'll
> try to merge your changes into my branch first, then come up with a
> patch set or try to merge back the stabilized version into the
> integration branch.
>

Cut from trunk.  And I merged your changes from urllib-dean, so merging them
back should be trivial.


>
> Please expect something within the next couple of days.
>
> Cool.  I won't be able to do much until the weekend.
G

Re: [cpp-netlib-devel] Updated 0.4 integration branch

[John P. F. <jf...@ov...>]

Glyn Matthews wrote:
> 1. boost::network::uri::uri and boost::network::uri::http::uri have a
> redundant namespace.  I understand that the directives maybe shouldn't be in
> boost::network, but a different named namespace might be better so that we
> could have boost::network::uri and boost::network::http::uri.
>   
I think that directives which perform requirements of the uri API should 
be within a boost::network::uri namespace.  If it handles something 
specific to http uri -though not necessarily at exactly 
boost::network::uri::http-  either the associated tag should be within 
::http, or the function or class which handles http specific things 
should be. So in short there is no easy answer, it depends on things 
like cross cutting concerns, and what boost::network::uri means ( I'll 
put what I've discussed here in the design spec for revision).
> 2. I had to do some workarounds with the wrappers and directives to add
> support for std::wstring.
>   
Thanks!
> 3. I need clarification as to why there should be tags to identify different
> protocols.  I understand the need to specialize templates for strings and
> header_containers but I can't see why we have, e.g.
> boost::network::http::message_tags to specialize
> boost::network::http::basic_message as we do now.  this means we have to
> provide traits for struct string<http::message_tags> as well as
> string<tags::default_> which are in fact going to be identical.
>   
> 4. I don't like the name, tags::default_.  I added tags::default_string and
> tags::default_wstring, and, while they're more descriptive, I think they can
> be improved.
> 5. Internally, we sometimes use namespace impl and sometimes namespace
> detail.  We should be more consistent and choose one.
> 6. The implementation of http::message and http::message uses std::string
>   
No comment in regards to the rest, as I think Dean is currently in a 
better position to answer.

John

Re: [cpp-netlib-devel] Updated 0.4 integration branch

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

Hi Glyn!

I apologize for taking a while to respond, I've been kept busy with
some daytime work related issues. I'm past these now and am in the
process of dealing with the backlog.

Please see my thoughts below.

On Mon, Nov 16, 2009 at 3:52 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi,
>
>
> I've updated integration_0_4 and made an attempt to improve the unit tests
> therein.  The basic_message and basic_uri templates now are tested using
> std::wstring as a parameter, and this seems to work.  I have made some
> observations that I'd like to discuss with the list.
>

Thanks! That sounds like great progress to me.

> 1. boost::network::uri::uri and boost::network::uri::http::uri have a
> redundant namespace.  I understand that the directives maybe shouldn't be in
> boost::network, but a different named namespace might be better so that we
> could have boost::network::uri and boost::network::http::uri.

Do you have any proposals for that different namespace?

> 2. I had to do some workarounds with the wrappers and directives to add
> support for std::wstring.

Yeah, I think there should be a better way of doing directives in a
more generic manner like using either CRTP or PBCP correctly. Let me
get back to that at a later time, maybe once we finalize the uri
implementation.

> 3. I need clarification as to why there should be tags to identify different
> protocols.  I understand the need to specialize templates for strings and
> header_containers but I can't see why we have, e.g.
> boost::network::http::message_tags to specialize
> boost::network::http::basic_message as we do now.  this means we have to
> provide traits for struct string<http::message_tags> as well as
> string<tags::default_> which are in fact going to be identical.

The reasoning for this is so that we can have different interfaces for
the different specializations of basic_message. Although we might
probably be able to get away with a Message concept which is opaque
and can be checked/enforced by BCCL, my concern for that would be the
lack of "specialization" for writing generic algorithms that might be
able to do tag dispatching. For instance:

  template <class Tag>
  void foo(basic_message<Tag> const & msg) {
    bar(msg, Tag()); // use tag dispatching
  }

This also allows us to specialize some operations on basic_messages:

  template <class Tag, class Transformation>
  basic_message<Tag> transform(basic_message<Tag> const & msg,
transformation<Transformation> f) {
    return f(msg);
  }

Although this might work with BCCL using opaque types, it's worth a
shot. Again let me look back at cleaning up the message abstraction
and algorithms at a later time.

> 4. I don't like the name, tags::default_.  I added tags::default_string and
> tags::default_wstring, and, while they're more descriptive, I think they can
> be improved.

The intention in my brain for tags::default_ was not just for what
kind of strings to use, but also for default implementations for
example of the HTTP client and the basic_message template. The
default_ tag was meant to be the default implementation for anything
that was being shipped with the library -- and traits were dispatched
according to that tag. This allows for using compile-time flags to
switch the default typedef for boost::network::message from
`boost::network::basic_message<tags::default_>` to
`boost::network::basic_message<tags::special>` or something to that
effect.

> 5. Internally, we sometimes use namespace impl and sometimes namespace
> detail.  We should be more consistent and choose one.

I think personally there's a distinction, but I won't fight for impl.
In my mind impl:: is supposed to be just for implementations, while
detail:: can also implement helpers and utility classes, etc.;
detail::impl:: might make sense but then that would be too much
nesting even for me. ;)

I like detail and it follows the boost tradition.

> 6. The implementation of http::message and http::message uses std::string
>

Yeah, I should change that really. File Trac tickets? :) I don't
receive emails though, is there something that I should do special to
get alerts on new tickets filed and assigned to me?

> Please try and run the tests and let me know if there are any other issues.
> Dean and John, perhaps you could be able to see if the updates work with
> what you're both trying to do.
>

Is the branch cut from trunk, or was it cut from somewhere else? I'll
try to merge your changes into my branch first, then come up with a
patch set or try to merge back the stabilized version into the
integration branch.

Please expect something within the next couple of days.

Thanks again Glyn and I hope this helps!

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

[cpp-netlib-devel] Updated 0.4 integration branch

[Glyn M. <gly...@gm...>]

Hi,


I've updated integration_0_4 and made an attempt to improve the unit tests
therein.  The basic_message and basic_uri templates now are tested using
std::wstring as a parameter, and this seems to work.  I have made some
observations that I'd like to discuss with the list.

1. boost::network::uri::uri and boost::network::uri::http::uri have a
redundant namespace.  I understand that the directives maybe shouldn't be in
boost::network, but a different named namespace might be better so that we
could have boost::network::uri and boost::network::http::uri.
2. I had to do some workarounds with the wrappers and directives to add
support for std::wstring.
3. I need clarification as to why there should be tags to identify different
protocols.  I understand the need to specialize templates for strings and
header_containers but I can't see why we have, e.g.
boost::network::http::message_tags to specialize
boost::network::http::basic_message as we do now.  this means we have to
provide traits for struct string<http::message_tags> as well as
string<tags::default_> which are in fact going to be identical.
4. I don't like the name, tags::default_.  I added tags::default_string and
tags::default_wstring, and, while they're more descriptive, I think they can
be improved.
5. Internally, we sometimes use namespace impl and sometimes namespace
detail.  We should be more consistent and choose one.
6. The implementation of http::message and http::message uses std::string

Please try and run the tests and let me know if there are any other issues.
Dean and John, perhaps you could be able to see if the updates work with
what you're both trying to do.


Glyn

Re: [cpp-netlib-devel] Query string parsing

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

Hi Glyn and Jeroen,

On Tue, Nov 10, 2009 at 8:49 PM, Glyn Matthews <gly...@gm...> wrote:
> Hello Jeroen,
>
> 2009/11/10 Jeroen Habraken <vex...@gm...>
>>
>> Hi,
>>
>> I've been looking at cpp-netlib and it's great to finally see a
>> library focussing on the network side, and HTTP in specific. I was
>> wondering though if any of the current URI parsing implementations can
>> be used to parse the query-string of a URI into a map ?
>>
>
> Yeah this should certainly be possible but at the moment we're still working
> on the implementation so as yet, no working URI code.  If you're interested
> and you have any suggestions you can contribute to the discussions on the
> wiki:
>
> http://sourceforge.net/apps/trac/cpp-netlib/wiki/URIAPIRequirements
>
> I don't know yet, but I imagine something similar to:
>
> namespace bn = boost::network;
> bn::http::uri instance("http://example.com/?foo=bar&x=y")
> std::string scheme, host, path;
> std::map<std::string, std::string> query_params;
> instance >> bn::scheme(scheme)
>          >> bn::host(host)
>          >> bn::path(path)
>          >> bn::query(query_params);

This part I think can be simplified into something like this
(untested/unimplemented yet):

  scheme = scheme(instance); // adl takes care of it for us
  host = host(instance);
  path = path(instance);
  query_params_map = query(instance); // returns a proxy object convertible to
  query_params_string = query(instance); // either a map or a string

Although I like the directive-based API (consistent with the message
directive-based API) I think for a URI implementation that might be a
little too verbose. ;)

I can also imagine something like this:

  tie(scheme, host, path, query_params) = parts(instance);

I personally think there's a lot of opportunity for this space to be
explored, and offering many different APIs (like those discussed above
proposed by Glyn and I) would definitely be nice. :)

> assert(scheme == "http");
> assert(host == "example.com");
> assert(path == "/");
> assert(query_params["foo"] == "bar");
> assert(query_params["x"] == "y");
>

Looks like the beginnings of a test to me. ;) Glyn/Jeroen would you
like to file this as a Trac feature request assigned to me?

Thanks in advance! :D

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Query string parsing

[Glyn M. <gly...@gm...>]

Hello Jeroen,

2009/11/10 Jeroen Habraken <vex...@gm...>

> Hi,
>
> I've been looking at cpp-netlib and it's great to finally see a
> library focussing on the network side, and HTTP in specific. I was
> wondering though if any of the current URI parsing implementations can
> be used to parse the query-string of a URI into a map ?
>
>
Yeah this should certainly be possible but at the moment we're still working
on the implementation so as yet, no working URI code.  If you're interested
and you have any suggestions you can contribute to the discussions on the
wiki:

http://sourceforge.net/apps/trac/cpp-netlib/wiki/URIAPIRequirements

I don't know yet, but I imagine something similar to:

namespace bn = boost::network;
bn::http::uri instance("http://example.com/?foo=bar&x=y")
std::string scheme, host, path;
std::map<std::string, std::string> query_params;
instance >> bn::scheme(scheme)
         >> bn::host(host)
         >> bn::path(path)
         >> bn::query(query_params);
assert(scheme == "http");
assert(host == "example.com");
assert(path == "/");
assert(query_params["foo"] == "bar");
assert(query_params["x"] == "y");


Regards,
Glyn

[cpp-netlib-devel] Query string parsing

[Jeroen H. <vex...@gm...>]

Hi,

I've been looking at cpp-netlib and it's great to finally see a
library focussing on the network side, and HTTP in specific. I was
wondering though if any of the current URI parsing implementations can
be used to parse the query-string of a URI into a map ?

Yours,
Jeroen Habraken

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[John P. F. <jf...@ov...>]

Dean Michael Berris wrote:
> Hi John,
>
> On Fri, Nov 6, 2009 at 8:56 PM, John P. Feltz <jf...@ov...> wrote:
>   
>> I don't see any compelling reason for either git vs svn or sf vs github.
>> I only see a time cost that would be better spent on actually improving
>> the library. Merging in SVN from what I've seen is fairly trivial, it is
>> the design decisions that are hard -and those can be addressed through
>> work on the specs and subsequent division between Dean and myself
>> (currently).
>>
>>     
>
> I am not sure where the division is though. What I have stated before
> about how to go forward has been clear in both my mind and the code
> I've written. The tests are the specification for what features I'm
> looking for in a header-only URI library.
>   
Testing code is fine, however among other benefits, a document is easier 
to use for reaching consensus prior to coding (a much more laborious 
process without that).

> Let me know how I can close the division from my end.
>   
I was referring to the benefit of a clear division of labor that 
documents and people help establish.

John

Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

On Mon, Nov 9, 2009 at 11:47 PM, Dean Michael Berris
<mik...@gm...> wrote:
>
> Ah, yes. I keep forgetting we have a Trac installation. :)
>
> I'll send the ticket number to the list after I do it. :D
>

https://sourceforge.net/apps/trac/cpp-netlib/ticket/10

HTH!

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

On Mon, Nov 9, 2009 at 9:20 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> 2009/11/9 Dean Michael Berris <mik...@gm...>
>>
>
> <snip>
>>
>> Do either of you mind doing this on my URI implementation branch?
>> Maybe merging John's tests and mine into a single "coherent" test
>> suite? :D
>>
>> BTW, does anybody want to take on a URL-encoding template function
>> that uses Boost.Spirit 2.1's Karma library? It'd be good to have that
>> function implemented as a standalone function so that we can write
>> user code like this:
>>
>>  http::uri instance = string("http://foo.bar.com/q?") +
>> urlencode("yadda='The quick brown fox! Jumps over the lazy
>> dog?#)(*#)@");
>>
>
> Please create Trac tickets for any ideas that you want others to pick up,
> they'll just get lost on the mailing list.
>

Ah, yes. I keep forgetting we have a Trac installation. :)

I'll send the ticket number to the list after I do it. :D

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Glyn M. <gly...@gm...>]

Hi Dean,

2009/11/9 Dean Michael Berris <mik...@gm...>

>
>
<snip>

> Do either of you mind doing this on my URI implementation branch?
> Maybe merging John's tests and mine into a single "coherent" test
> suite? :D


> BTW, does anybody want to take on a URL-encoding template function
> that uses Boost.Spirit 2.1's Karma library? It'd be good to have that
> function implemented as a standalone function so that we can write
> user code like this:
>
>  http::uri instance = string("http://foo.bar.com/q?") +
> urlencode("yadda='The quick brown fox! Jumps over the lazy
> dog?#)(*#)@");
>
>
Please create Trac tickets for any ideas that you want others to pick up,
they'll just get lost on the mailing list.

G

Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

On Mon, Nov 9, 2009 at 4:31 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi Kim,
>
> 2009/11/9 Kim Gräsman <kim...@gm...>
>>
>> Hi guys,
>>
>> On Sun, Nov 8, 2009 at 22:21, Glyn Matthews <gly...@gm...>
>> wrote:
>> >
>> >> > Consequently, I'd like to see all your unit tests repeated for
>> >> > std::wstring.  I think this is important to do because it will really
>> >> > justify the approach we are taking.
>> >>
>> >> I agree. Can this be done automatically? Copy-paste-replace?
>> >
>> > I wouldn't recommend copy-paste programming ;) Perhaps just refactor the
>> > original tests so that they use template member functions:
>> >
>> > BOOST_AUTO_TEST_CASE(my_uri_test) {
>> >     boost::network::basic_uri<tags::default_> instance;
>> >     my_uri_test_impl(instance);
>> > }
>> >
>> > BOOST_AUTO_TEST_CASE(my_uri_test_wstring) {
>> >     boost::network::basic_uri<tags::wstring> instance;
>> >     my_uri_test_impl(instance);
>> > }
>> >
>> > or something like that, it won't be difficult.  But looking at that,
>> > we'll
>> > need better names for the tags.
>>
>> For the xUnit, OO-style, test frameworks there's a pattern called
>> Abstract Test Case, where all test methods reside in a base class,
>> together with one or more abstract methods denoting variance. Then you
>> create derived, concrete classes that implement the variations for the
>> specific types, and the runner sees them as separate suites.
>>
>> That's essentially what you're describing above, except you would have
>> to repeat every test case for every variation.
>>
>> I wonder if there's a way to use Boost.Test fixtures to implement
>> Abstract Test Case with a type variation...?
>>
>
> This seems to be the recommended usage pattern for testing generic
> components with different template patterns:
> http://www.boost.org/doc/libs/1_40_0/libs/test/doc/html/utf/usage-recommendations/generic.html#id663542
>

Great find Glyn! Yup, this looks like the way to do it. :-)

Also, there's a way to have fixtures too (like setUp and tearDown) --
I don't know if we use this yet in the project, but I remember using
this for one of my proprietary projects back then. :)

Do either of you mind doing this on my URI implementation branch?
Maybe merging John's tests and mine into a single "coherent" test
suite? :D

BTW, does anybody want to take on a URL-encoding template function
that uses Boost.Spirit 2.1's Karma library? It'd be good to have that
function implemented as a standalone function so that we can write
user code like this:

  http::uri instance = string("http://foo.bar.com/q?") +
urlencode("yadda='The quick brown fox! Jumps over the lazy
dog?#)(*#)@");

HTH :)

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Updates on urllib-dean branch

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

Hi Glyn!

On Mon, Nov 9, 2009 at 5:21 AM, Glyn Matthews <gly...@gm...> wrote:
>
>
> 2009/11/8 Dean Michael Berris <mik...@gm...>
>>
[snip]
>>
>> Yes, I like this. However, I don't want to glob the data into traits
>> classes. Let's come up with some other name that's dependent on the
>> tag, but is not called traits.
>>
>
> Are you suggesting each delimiting string be in it's own class,  or just a
> rename of the uri_traits class?  I never intended it to be a glob, but
> uri_traits is certainly the wrong name.  What about uri_delimiters?
>

I would want to move them into one class each -- that way in case we
need to add more 'constants' we don't change a globbed together class
that easily grows and becomes unweildy -- also, it also allows us to
re-use these in other contexts. It doesn't hurt to have them
individually in different classes either, except maybe the duplication
of opening and closing braces. ;)

I would make a namespace which contains the delimiters, something like
'boost::network::uri::detail::delimeters' and have each class named
appropriately like 'detail::delimeters::colon<Tag>::char_()' or
'detail::delimeters::question_mark<Tag>::char_()'.

For the first try though if you'd like to implement it with a single
'delimeters' type with a tag and then call the static functions by
name like 'detail::delimeters<Tag>::question_mark()', please be my
guest. Changing later on should not be a problem since it's an
implementation detail. ;)

>> > Consequently, I'd like to see all your unit tests repeated for
>> > std::wstring.  I think this is important to do because it will really
>> > justify the approach we are taking.
>>
>> I agree. Can this be done automatically? Copy-paste-replace?
>
> I wouldn't recommend copy-paste programming ;) Perhaps just refactor the
> original tests so that they use template member functions:
>
> BOOST_AUTO_TEST_CASE(my_uri_test) {
>     boost::network::basic_uri<tags::default_> instance;
>     my_uri_test_impl(instance);
> }
>
> BOOST_AUTO_TEST_CASE(my_uri_test_wstring) {
>     boost::network::basic_uri<tags::wstring> instance;
>     my_uri_test_impl(instance);
> }
>
> or something like that, it won't be difficult.  But looking at that, we'll
> need better names for the tags.

I agree. Would you make it happen and let me know so that I can pull
your changes? :D

>>
>> >
>> > Is there a reason why you're providing the HTTP URI under
>> > boost/network/uri/http and not boost/network/protocols/http ?
>> >
>>
>> Because I was thinking the URI library is something can be used
>> externally, it's feasible that we can package it as a separate library
>> to be downloaded and used in other packages. I don't mind moving it
>> though, it makes sense in either location. :D
>>
>
> Perhaps, but as a header-only library, does this matter?  As long as the
> headers don't pull in unnecessary dependencies, I think it's better to keep
> them grouped by protocol.  I think this will be much clearer when we add
> more protocols.
>

Yeah, I guess. Feel free to move them around -- also let me know when
it's done so that I can pull your changes. :D

>>
>> This bothers me a little too. I think we ought to merge the
>> implementations somewhere before merging to trunk -- I haven't been
>> following John's developments, but we can try and merge the tests
>> first, consolidate them so that we can use different implementations
>> underneath.
>>
>> One thing that I like doing is to keep the design and implementation
>> as simple as possible -- and I really am not big on pre-design,
>> because the way I do it is that I try many different things and then
>> distill into an implementation that I like. I would love to make that
>> process more transparent and more "a-priori". Maybe we can do a skype
>> call and coordinate, I can better explain without doing any writing?
>>
>> What I am open to is to try a merge of the tests first -- then let's
>> take approaches from one branch (from John's) and merge them into
>> another branch (uri?). If you can try and do this Glyn, and and have
>> everyone work on the same branch to stabilize the implementation, then
>> we can work on moving in the same direction.
>>
>> How that that sound? (BTW, in Git this would be really "simple" to do. ;)
>> )
>
> Perhaps, but the change to Git probably shouldn't happen midway through a
> development cycle.  I will continue to use integration_0_4, and I'll merge
> your's and John's tests.  I'll try and find time to do that this coming
> week.
>

Sounds great Glyn, thanks for taking this on!

-- 
Dean Michael Berris
blog.cplusplus-soup.com | twitter.com/mikhailberis
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Glyn M. <gly...@gm...>]

Hi Kim,

2009/11/9 Kim Gräsman <kim...@gm...>

> Hi guys,
>
> On Sun, Nov 8, 2009 at 22:21, Glyn Matthews <gly...@gm...>
> wrote:
> >
> >> > Consequently, I'd like to see all your unit tests repeated for
> >> > std::wstring.  I think this is important to do because it will really
> >> > justify the approach we are taking.
> >>
> >> I agree. Can this be done automatically? Copy-paste-replace?
> >
> > I wouldn't recommend copy-paste programming ;) Perhaps just refactor the
> > original tests so that they use template member functions:
> >
> > BOOST_AUTO_TEST_CASE(my_uri_test) {
> >     boost::network::basic_uri<tags::default_> instance;
> >     my_uri_test_impl(instance);
> > }
> >
> > BOOST_AUTO_TEST_CASE(my_uri_test_wstring) {
> >     boost::network::basic_uri<tags::wstring> instance;
> >     my_uri_test_impl(instance);
> > }
> >
> > or something like that, it won't be difficult.  But looking at that,
> we'll
> > need better names for the tags.
>
> For the xUnit, OO-style, test frameworks there's a pattern called
> Abstract Test Case, where all test methods reside in a base class,
> together with one or more abstract methods denoting variance. Then you
> create derived, concrete classes that implement the variations for the
> specific types, and the runner sees them as separate suites.
>
> That's essentially what you're describing above, except you would have
> to repeat every test case for every variation.
>
> I wonder if there's a way to use Boost.Test fixtures to implement
> Abstract Test Case with a type variation...?
>
>
This seems to be the recommended usage pattern for testing generic
components with different template patterns:
http://www.boost.org/doc/libs/1_40_0/libs/test/doc/html/utf/usage-recommendations/generic.html#id663542

Thanks,
Glyn

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Kim G. <kim...@gm...>]

Hi guys,

On Sun, Nov 8, 2009 at 22:21, Glyn Matthews <gly...@gm...> wrote:
>
>> > Consequently, I'd like to see all your unit tests repeated for
>> > std::wstring.  I think this is important to do because it will really
>> > justify the approach we are taking.
>>
>> I agree. Can this be done automatically? Copy-paste-replace?
>
> I wouldn't recommend copy-paste programming ;) Perhaps just refactor the
> original tests so that they use template member functions:
>
> BOOST_AUTO_TEST_CASE(my_uri_test) {
>     boost::network::basic_uri<tags::default_> instance;
>     my_uri_test_impl(instance);
> }
>
> BOOST_AUTO_TEST_CASE(my_uri_test_wstring) {
>     boost::network::basic_uri<tags::wstring> instance;
>     my_uri_test_impl(instance);
> }
>
> or something like that, it won't be difficult.  But looking at that, we'll
> need better names for the tags.

For the xUnit, OO-style, test frameworks there's a pattern called
Abstract Test Case, where all test methods reside in a base class,
together with one or more abstract methods denoting variance. Then you
create derived, concrete classes that implement the variations for the
specific types, and the runner sees them as separate suites.

That's essentially what you're describing above, except you would have
to repeat every test case for every variation.

I wonder if there's a way to use Boost.Test fixtures to implement
Abstract Test Case with a type variation...?

- Kim

Re: [cpp-netlib-devel] Updates on urllib-dean branch

[Glyn M. <gly...@gm...>]

2009/11/8 Dean Michael Berris <mik...@gm...>

> Hi Glyn!
>
> On Sun, Nov 8, 2009 at 7:40 PM, Glyn Matthews <gly...@gm...>
> wrote:
> > Having said that though, I think the traits systems need to be extended,
> > because your HTTP URI can't be specialized for std::wstring (or for any
> > string which doesn't have an 8 bit character length).
> >
>
> Right...
>
> > I would suggest something along the lines of:
> >
> > namespace boost {
> > namespace network {
> > template <
> >     class Tag
> >     >
> > struct uri_traits {
> >     typedef typename string<Tag>::type string_type;
> >
> >     typedef boost::uint32_t port_type;
> >
> >     static const string_type &colon() {
> >         static const string_type colon = ":";
> >         return colon;
> >     }
> >
> >     static const string_type &qmark() {
> >         static const string_type qmark = "?";
> >         return qmark;
> >     }
> >
> >     static const string_type &pound() {
> >         static const string_type pound = "#";
> >         return pound;
> >     }
> > };
> >
> >
> > template <>
> > struct uri_traits<tags::wdefault> {
> >     typedef string<tags::wdefault>::type string_type;
> >
> >     typedef boost::uint32_t port_type;
> >
> >     static const string_type &colon() {
> >         static const string_type colon = L":";
> >         return colon;
> >     }
> >
> >     static const string_type &qmark() {
> >         static const string_type qmark = L"?";
> >         return qmark;
> >     }
> >
> >     static const string_type &pound() {
> >         static const string_type pound = L"#";
> >         return pound;
> >     }
> > };
> > } // namespace network
> > } // namespace boost
> >
> >
> > Do you agree with this?  Unless I'm missing something, your spirit parser
> > only needs to know a small number of special delimiting characters and
> the
> > rest is generic because you then don't need to specify the string type
> > internally.  I don't think this would easily extend to John's
> implementation
> > though, but his code suffers from the same problem (it uses std::string a
> > lot internally and isn't generic).
> >
>
> Yes, I like this. However, I don't want to glob the data into traits
> classes. Let's come up with some other name that's dependent on the
> tag, but is not called traits.
>
>

Are you suggesting each delimiting string be in it's own class,  or just a
rename of the uri_traits class?  I never intended it to be a glob, but
uri_traits is certainly the wrong name.  What about uri_delimiters?

> Consequently, I'd like to see all your unit tests repeated for
> > std::wstring.  I think this is important to do because it will really
> > justify the approach we are taking.
>
> I agree. Can this be done automatically? Copy-paste-replace?
>

I wouldn't recommend copy-paste programming ;) Perhaps just refactor the
original tests so that they use template member functions:

BOOST_AUTO_TEST_CASE(my_uri_test) {
    boost::network::basic_uri<tags::default_> instance;
    my_uri_test_impl(instance);
}

BOOST_AUTO_TEST_CASE(my_uri_test_wstring) {
    boost::network::basic_uri<tags::wstring> instance;
    my_uri_test_impl(instance);
}

or something like that, it won't be difficult.  But looking at that, we'll
need better names for the tags.

>
> >
> > Is there a reason why you're providing the HTTP URI under
> > boost/network/uri/http and not boost/network/protocols/http ?
> >
>
> Because I was thinking the URI library is something can be used
> externally, it's feasible that we can package it as a separate library
> to be downloaded and used in other packages. I don't mind moving it
> though, it makes sense in either location. :D
>
>
Perhaps, but as a header-only library, does this matter?  As long as the
headers don't pull in unnecessary dependencies, I think it's better to keep
them grouped by protocol.  I think this will be much clearer when we add
more protocols.


> > On another note, I'd like to get more involved with the development of
> the
> > URI but I'm finding it difficult to know exactly where to join, since
> there
> > are two completely different branches.  For one, I'd like to add the
> wstring
> > unit tests I mentioned above (and actually some more for basic_message)
> but
> > I don't know in what branch I should because your's and John's have
> diverged
> > to a large extent.  I could do this either in trunk, or in
> integration_0_4
> > but they might just end up being ignored.  In fact, this is a more
> general
> > problem with the way we develop, I think, because it prevents other
> people
> > from contributing code or tests or docs.  Any thoughts?
> >
>
> This bothers me a little too. I think we ought to merge the
> implementations somewhere before merging to trunk -- I haven't been
> following John's developments, but we can try and merge the tests
> first, consolidate them so that we can use different implementations
> underneath.
>
> One thing that I like doing is to keep the design and implementation
> as simple as possible -- and I really am not big on pre-design,
> because the way I do it is that I try many different things and then
> distill into an implementation that I like. I would love to make that
> process more transparent and more "a-priori". Maybe we can do a skype
> call and coordinate, I can better explain without doing any writing?
>
> What I am open to is to try a merge of the tests first -- then let's
> take approaches from one branch (from John's) and merge them into
> another branch (uri?). If you can try and do this Glyn, and and have
> everyone work on the same branch to stabilize the implementation, then
> we can work on moving in the same direction.
>
> How that that sound? (BTW, in Git this would be really "simple" to do. ;) )
>

Perhaps, but the change to Git probably shouldn't happen midway through a
development cycle.  I will continue to use integration_0_4, and I'll merge
your's and John's tests.  I'll try and find time to do that this coming
week.


Glyn