cpp-netlib-devel — Developers Mailing List

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Kim,

On Mon, Oct 13, 2008 at 8:45 PM, Kim Gräsman <kim...@gm...> wrote:
>
> On Mon, Oct 13, 2008 at 14:39, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>>> So with every template that needs a new tag, but shares traits with
>>> existing classes/templates (typically string, ostringstream, char_),
>>> we have to duplicate these definitions.
>>>
>>
>> Do you really need a new tag?
>
> Nope, I don't think so, I was just wondering whether this was the
> issue. I got confused with the http::message_tag.
>

Okay. :)

>> The reason we have a http::message_tag is because there are traits
>> supported by http::message_tag that don't support the default_ tag.
>> It's also a point of customization intended for extension -- so if you
>> want a different storage mechanism for HTTP Messages (like unordered
>> multi-maps for headers, etc.) then you create your own tag and
>> specialize the traits you want to support explicitly.
>
> Yes. But since that tag will be used throughout the implementation,
> passed on to basic_request, basic_message, etc., I'd have to
> specialize all traits for the new tag, even if I'm only changing one,
> right? I think that's where my ability to picture this breaks :)
>

Actually, not really -- or as far as I recall, not at all.

Consider the example below:

template <class Tag>
struct string {
  typedef std::string type;
};

template <>
struct string<tags::wide_default> {
  typedef std::wstring type;
};

If you really needed to customize with your own tag, then you can
override the default implementation (unspecialized version). :-D

>> I'd even think we should promote the traits for the message class to a
>> higher traits namespace, to be (re)used throughout the project. ;-)
>
> Right, I think that makes sense, that was my original problem.
>

Okay. In the meantime, I think it's merely a matter of including the
correct traits from network/message/traits and then in the future
doing a more far-reaching refactoring of the source. :-)

>>> Does that even make sense? :)
>>
>> I think I'm still missing details as to why you need a separate tag
>> apart from the default_ tag that's already available.
>
> I don't think there's a reason. I think I'm beginning to see how this
> fits together, but it's still a little blurry :)
>

Okay. I hope the above example helps. :-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] Strings and standards (Was URI processing (Was Re: Work Left))

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

On Mon, Oct 13, 2008 at 8:32 PM, Glyn Matthews <gly...@gm...> wrote:
>
> 2008/10/13 Kim Gräsman <kim...@gm...>
>>
>> I wonder if what Glyn is looking for is something like:
>>
>> template <> char_based_traits<network::tags::default_> {
>>  typedef std::string string_type;
>>  typedef std::ostringstream ostringstream_type;
>>  typedef char char_type;
>> };
>>
>> so that related traits are defined together, and orthogonal traits
>> separately. Just guessing, though. But it doesn't make intuitive sense
>> to me to specialize them separated from each other, when they're all
>> based on the definition of char.
>>
>
> Yes but I want to go further and say why can't we used std::char_traits
> directly?  I understand that this prevents us from using our own string
> types that don't use basic_string, but if we're going to use ostringstream
> internally anyway, why do we make it more difficult for ourselves?
>

Okay, the reasons for the additional layer of indirection are:

1. To support non standard string implementations and consequently
string buffer implementations (think MS CString and CStringBuffer (?)
).
2. To be able to customize the ostringstream implementation on a
per-tag basis (for example, a standards conforming but Boost.Pool
based ostringstream implementation, or a Boost.IOStreams based
implementation, etc.) but still uses standard strings for the type.
3. To be able to switch implementations globally eventually through
compiler macro's (for example, in some systems tags::default_ may
specify different types for string, ostringstream, etc. (think MS and
playing with MFC/ATL, or playing with ICU buffers for example, and Qt
strings, etc.)).

So it's not really "making it difficult for ourselves". It's preparing
for future eventualities really. ;-)

Currently, if you look at the http::client code, it makes a lot of
assumptions hard-coded as far as types are concerned. There is no easy
way of currently supporting wide character transfer support over the
wire, for which we'll need to factor out the string types, the string
buffer types, and even the literal caracter types/values. So that work
still needs to be done, and the best way to go about it really is to
make the string buffer, string, and character literal types/values
customizable on a tag.

There will also have to be special conversion handlers because for
example getting raw strings over the wire may require conversion from
7-bit characters to wide characters, and even special transfer
requirements (think compression and proprietary encryption support)
which I am anticipating will come as we go along. ;-)

> Taking the long view and we target eventual inclusion into boost, would it
> be better to use the standard way of doing this? cf. Boost.Filesystem?
>

In this vein, I think it's better we go about traits the correct way
-- which is like how Boost.Type_traits does it, one trait accessor
(type) at a time. :-)

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Dean & Glyn,

On Mon, Oct 13, 2008 at 14:39, Dean Michael Berris
<mik...@gm...> wrote:
>
>> So with every template that needs a new tag, but shares traits with
>> existing classes/templates (typically string, ostringstream, char_),
>> we have to duplicate these definitions.
>>
>
> Do you really need a new tag?

Nope, I don't think so, I was just wondering whether this was the
issue. I got confused with the http::message_tag.

> The reason we have a http::message_tag is because there are traits
> supported by http::message_tag that don't support the default_ tag.
> It's also a point of customization intended for extension -- so if you
> want a different storage mechanism for HTTP Messages (like unordered
> multi-maps for headers, etc.) then you create your own tag and
> specialize the traits you want to support explicitly.

Yes. But since that tag will be used throughout the implementation,
passed on to basic_request, basic_message, etc., I'd have to
specialize all traits for the new tag, even if I'm only changing one,
right? I think that's where my ability to picture this breaks :)

> I'd even think we should promote the traits for the message class to a
> higher traits namespace, to be (re)used throughout the project. ;-)

Right, I think that makes sense, that was my original problem.

>> Does that even make sense? :)
>
> I think I'm still missing details as to why you need a separate tag
> apart from the default_ tag that's already available.

I don't think there's a reason. I think I'm beginning to see how this
fits together, but it's still a little blurry :)

Cheers,
- Kim

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Dean,

2008/10/13 Dean Michael Berris <mik...@gm...>

> On Mon, Oct 13, 2008 at 8:05 PM, Kim Gräsman <kim...@gm...>
> wrote:
> >
> > I wonder if what Glyn is looking for is something like:
> >
> > template <> char_based_traits<network::tags::default_> {
> >  typedef std::string string_type;
> >  typedef std::ostringstream ostringstream_type;
> >  typedef char char_type;
> > };
> >
> > so that related traits are defined together, and orthogonal traits
> > separately. Just guessing, though. But it doesn't make intuitive sense
> > to me to specialize them separated from each other, when they're all
> > based on the definition of char.
> >
>
> This is the same problem the standard iterator traits introduce -- a
> blob -- which is bad design, and very unwieldy.
>

I understand the problem with blobs,  but my question related to standards
remains: would it be more advantageous to use this more flexible design than
to wander too far from the standard mechanism?  Especially considering that
string, char_ and ostringstream are tightly coupled.
G

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

On Mon, Oct 13, 2008 at 7:58 PM, Kim Gräsman <kim...@gm...> wrote:
> HI Glyn,
>
> On Mon, Oct 13, 2008 at 11:47, Glyn Matthews <gly...@gm...> wrote:
>>
>>> Most of the specializations are useful on a global level, but at the
>>> same time it would be nice to keep the specializations close to the
>>> code that uses them, rather than listing unrelated but similar specs
>>> (string<message_tag>, string<uri_tag>) one after another.
>>>
>>> I don't have any good suggestions... Is there a way of reusing
>>> tag/traits definitions, so that one can create a 'base' definition
>>> with the string stuff, and then 'derive' and add more
>>> protocol-specific definitions? I'm just thinking out loud...
>>
>> I'm not sure what you mean here.  Can you elaborate?
>
> Sure, I'll try.
>
> If we look at this specific example, where we've added basic_uri, it
> doesn't share tag with basic_message (default_tags vs.
> tags::default_).
>

Why not use tags::default_ like basic_message?

> So with every template that needs a new tag, but shares traits with
> existing classes/templates (typically string, ostringstream, char_),
> we have to duplicate these definitions.
>

Do you really need a new tag?

> That's why I was wondering if there's a mechanism to reuse the traits
> between different tags.
>

I don't think there's a need for a different tag if you intend to work
with the default tag, which is already defined in the library.

Unless you want another point of customization, in which case it's
better to just re-use the existing default_ tag.

The reason we have a http::message_tag is because there are traits
supported by http::message_tag that don't support the default_ tag.
It's also a point of customization intended for extension -- so if you
want a different storage mechanism for HTTP Messages (like unordered
multi-maps for headers, etc.) then you create your own tag and
specialize the traits you want to support explicitly.

I don't see a need for a basic_uri template to define it's own tag
different from the default_ tag especially if you just intend to
re-use the same traits used for the message traits.

I'd even think we should promote the traits for the message class to a
higher traits namespace, to be (re)used throughout the project. ;-)

> Does that even make sense? :)

I think I'm still missing details as to why you need a separate tag
apart from the default_ tag that's already available.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Kim,

2008/10/13 Kim Gräsman <kim...@gm...>

> HI Glyn,
>
> That's why I was wondering if there's a mechanism to reuse the traits
> between different tags.
>
> Does that even make sense? :)
>

That's what I thought in the first place.  I always intended default_tags
and tags::default_ to be the same thing in the end and that's what we should
try and achieve.
G

[cpp-netlib-devel] Strings and standards (Was URI processing (Was Re: Work Left))

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

Hi,

2008/10/13 Kim Gräsman <kim...@gm...>

> Hi Dean,
>
> On Mon, Oct 13, 2008 at 12:45, Dean Michael Berris
> <mik...@gm...> wrote:
> >
> >> On an unrelated note, doesn't using ostringstream always require
> >> basic_string?  And char_type is not orthogonal to string_type and
> char_type.
> >>
> >
> > template <> string<network::tags::default_> {
> >  typedef std::string type;
> > };
> >
> > template <> struct string<network::tags::wide_default_> {
> >  typedef std::wstring type;
> > };
> >
> > [...]
>
> I wonder if what Glyn is looking for is something like:
>
> template <> char_based_traits<network::tags::default_> {
>  typedef std::string string_type;
>  typedef std::ostringstream ostringstream_type;
>  typedef char char_type;
> };
>
> so that related traits are defined together, and orthogonal traits
> separately. Just guessing, though. But it doesn't make intuitive sense
> to me to specialize them separated from each other, when they're all
> based on the definition of char.
>
>
Yes but I want to go further and say why can't we used std::char_traits
directly?  I understand that this prevents us from using our own string
types that don't use basic_string, but if we're going to use ostringstream
internally anyway, why do we make it more difficult for ourselves?

Taking the long view and we target eventual inclusion into boost, would it
be better to use the standard way of doing this? cf. Boost.Filesystem?

Glyn

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

On Mon, Oct 13, 2008 at 8:05 PM, Kim Gräsman <kim...@gm...> wrote:
>
> I wonder if what Glyn is looking for is something like:
>
> template <> char_based_traits<network::tags::default_> {
>  typedef std::string string_type;
>  typedef std::ostringstream ostringstream_type;
>  typedef char char_type;
> };
>
> so that related traits are defined together, and orthogonal traits
> separately. Just guessing, though. But it doesn't make intuitive sense
> to me to specialize them separated from each other, when they're all
> based on the definition of char.
>

This is the same problem the standard iterator traits introduce -- a
blob -- which is bad design, and very unwieldy.

I think I've discussed this before as to why I don't like trait blobs
and why I prefer individual trait types. It has something to do with
extensibility and for enforcing good design.

At any rate, it _should_ remain as individual types instead of blobs
precisely because you only need to specify the trait supported --
sometimes it doesn't make sense to support for instance a
'transfer_buffer' trait type for other traits since it only applies to
protocol traits which involve customization of the
transfer_buffer<...>::type based on the tag.

Some traits don't need to be specialized for certain tags, and
mis-using these traits with unsupported tags should yield a clear
compile-time error which says that a specialization for a certain
trait type cannot be found.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

HI Glyn,

On Mon, Oct 13, 2008 at 11:47, Glyn Matthews <gly...@gm...> wrote:
>
>> Most of the specializations are useful on a global level, but at the
>> same time it would be nice to keep the specializations close to the
>> code that uses them, rather than listing unrelated but similar specs
>> (string<message_tag>, string<uri_tag>) one after another.
>>
>> I don't have any good suggestions... Is there a way of reusing
>> tag/traits definitions, so that one can create a 'base' definition
>> with the string stuff, and then 'derive' and add more
>> protocol-specific definitions? I'm just thinking out loud...
>
> I'm not sure what you mean here.  Can you elaborate?

Sure, I'll try.

If we look at this specific example, where we've added basic_uri, it
doesn't share tag with basic_message (default_tags vs.
tags::default_).

So with every template that needs a new tag, but shares traits with
existing classes/templates (typically string, ostringstream, char_),
we have to duplicate these definitions.

That's why I was wondering if there's a mechanism to reuse the traits
between different tags.

Does that even make sense? :)

- Kim

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Dean,

On Mon, Oct 13, 2008 at 12:45, Dean Michael Berris
<mik...@gm...> wrote:
>
>> On an unrelated note, doesn't using ostringstream always require
>> basic_string?  And char_type is not orthogonal to string_type and char_type.
>>
>
> template <> string<network::tags::default_> {
>  typedef std::string type;
> };
>
> template <> struct string<network::tags::wide_default_> {
>  typedef std::wstring type;
> };
>
> [...]

I wonder if what Glyn is looking for is something like:

template <> char_based_traits<network::tags::default_> {
 typedef std::string string_type;
 typedef std::ostringstream ostringstream_type;
 typedef char char_type;
};

so that related traits are defined together, and orthogonal traits
separately. Just guessing, though. But it doesn't make intuitive sense
to me to specialize them separated from each other, when they're all
based on the definition of char.

- Kim

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Glyn,

On Mon, Oct 13, 2008 at 5:47 PM, Glyn Matthews <gly...@gm...> wrote:
>
> 2008/10/13 Kim Gräsman <kim...@gm...>
>>
>> On Mon, Oct 13, 2008 at 04:04, Dean Michael Berris
>> > That raises a good issue though: should we have a single place to have
>> > the tags hierarchy depicted?
>> >
[snip code]
>>
>> It feels a little strange pushing the tags together, but I can't say
>> why, really... It creates sort of a hotspot, where everybody will have
>> to make edits in order to add new protocols, etc. That's probably not
>> a huge problem.
>
> It could be a problem.  I share your concern about this.  But I don't know a
> solution to this yet.
>

Yeah, I thought about it a little more, and instead of using a 'struct
tags' I think it should remain a namespace. So it'd look like:

namespace network { namespace tags {
  struct default_ { };
} }

That way we can add more tags to this central namespace as protocols
get implemented along the way.

>>
>> > That way we can build traits on top of this hierarchy under a
>> > different namespace 'traits':
>> >
>> > namespace network { namespace traits {
>> >  template <class Tag> string;
>> >  template <class Tag> buffer;
>> >  template <class Tag> ostringstream;
>> >  template <class Tag> char_;
>> >  // ...
>> > } }
>>
>> I think it makes sense to keep the traits together, there's bound to
>> be a lot of overlap (especially around strings).
>
> right.  But I think it might be better named:
> namespace network { namespace traits {
> template <class Tag> string_type;
> template <class Tag> buffer_type;
> template <class Tag> ostringstream_type;
> template <class Tag> char_type;
> }}
>

The _type will then be redundant for using traits:

template <> struct string_type<network::tags::default_> {
  typedef std::string type;
};

//...

string_type<>::type instance; // ugly? redundant _type and ::type?

> On an unrelated note, doesn't using ostringstream always require
> basic_string?  And char_type is not orthogonal to string_type and char_type.
>

template <> string<network::tags::default_> {
  typedef std::string type;
};

template <> struct string<network::tags::wide_default_> {
  typedef std::wstring type;
};

template <> struct ostringstream<network::tags::default_> {
  typedef std::ostringstream type;
};

template <> struct ostringstream<network::tags::default_> {
  typedef std::wstringstream type;
};

:-D

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi,

2008/10/13 Kim Gräsman <kim...@gm...>

> On Mon, Oct 13, 2008 at 04:04, Dean Michael Berris
> > That raises a good issue though: should we have a single place to have
> > the tags hierarchy depicted?
> >
> > I'm thinking:
> >
> > namespace network {
> >  struct tags {
> >    struct http {
> >      struct message {
> >        struct tag { };
> >      };
> >      // ...
> >    };
> >    struct message {
> >      struct tag { };
> >    };
> >    // ...
> >  };
> > }
>
> It feels a little strange pushing the tags together, but I can't say
> why, really... It creates sort of a hotspot, where everybody will have
> to make edits in order to add new protocols, etc. That's probably not
> a huge problem.
>

It could be a problem.  I share your concern about this.  But I don't know a
solution to this yet.


>
> > That way we can build traits on top of this hierarchy under a
> > different namespace 'traits':
> >
> > namespace network { namespace traits {
> >  template <class Tag> string;
> >  template <class Tag> buffer;
> >  template <class Tag> ostringstream;
> >  template <class Tag> char_;
> >  // ...
> > } }
>
> I think it makes sense to keep the traits together, there's bound to
> be a lot of overlap (especially around strings).



right.  But I think it might be better named:
namespace network { namespace traits {
template <class Tag> string_type;
template <class Tag> buffer_type;
template <class Tag> ostringstream_type;
template <class Tag> char_type;
}}

On an unrelated note, doesn't using ostringstream always require
basic_string?  And char_type is not orthogonal to string_type and char_type.


> > And specialize them as necessary as well?
>
> Most of the specializations are useful on a global level, but at the
> same time it would be nice to keep the specializations close to the
> code that uses them, rather than listing unrelated but similar specs
> (string<message_tag>, string<uri_tag>) one after another.
>
> I don't have any good suggestions... Is there a way of reusing
> tag/traits definitions, so that one can create a 'base' definition
> with the string stuff, and then 'derive' and add more
> protocol-specific definitions? I'm just thinking out loud...
>


I'm not sure what you mean here.  Can you elaborate?

Glyn

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Dean,

On Mon, Oct 13, 2008 at 04:04, Dean Michael Berris
<mik...@gm...> wrote:
>>
>> I created a branch succinctly called 'uri', on
>> https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri
>>
>> I've committed the first fumbling parts there, in
>> /boost/network/uri.hpp and /libs/network/test/uri_test.hpp.
>>
>
> Quick question: where did you branch from? trunk or http_integration?

>From trunk.

>> I didn't parameterize the string type mainly because the default tag
>> is under network/protocol/http, and the URI goes one level up in the
>> hierarchy, but I suppose I could introduce a temporary tag to wrap the
>> string typedef.
>
> That raises a good issue though: should we have a single place to have
> the tags hierarchy depicted?
>
> I'm thinking:
>
> namespace network {
>  struct tags {
>    struct http {
>      struct message {
>        struct tag { };
>      };
>      // ...
>    };
>    struct message {
>      struct tag { };
>    };
>    // ...
>  };
> }

It feels a little strange pushing the tags together, but I can't say
why, really... It creates sort of a hotspot, where everybody will have
to make edits in order to add new protocols, etc. That's probably not
a huge problem.

> That way we can build traits on top of this hierarchy under a
> different namespace 'traits':
>
> namespace network { namespace traits {
>  template <class Tag> string;
>  template <class Tag> buffer;
>  template <class Tag> ostringstream;
>  template <class Tag> char_;
>  // ...
> } }

I think it makes sense to keep the traits together, there's bound to
be a lot of overlap (especially around strings).

> And specialize them as necessary as well?

Most of the specializations are useful on a global level, but at the
same time it would be nice to keep the specializations close to the
code that uses them, rather than listing unrelated but similar specs
(string<message_tag>, string<uri_tag>) one after another.

I don't have any good suggestions... Is there a way of reusing
tag/traits definitions, so that one can create a 'base' definition
with the string stuff, and then 'derive' and add more
protocol-specific definitions? I'm just thinking out loud...

- Kim

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Glyn,

On Sun, Oct 12, 2008 at 12:52, Glyn Matthews <gly...@gm...> wrote:
>
> I've taken a look, and the tests seem OK.  It didn't compile on GCC because
> you'd left all the typenames in, but I did a bit of refactoring to fix
> this.  I made it a template (basic_url) and provided a default typedef.
> This is similar to the way we're using basic_message, so it's more
> consistent.  I think for basic_message and basic_url, it would eventually be
> necessary to refactor the traits because they will have a lot in common.

Yes, that was something I was thinking of as well, but I didn't want
to duplicate the tags/traits. For a start, though, this looks good,
then we can work towards unifying them.

I continued trying to get the tags/traits in place, but I never
managed to get it to work. I wasn't sure whether to base traits around
boost::network::default_tags or uri::tags -- the latter requires that
uri is defined, which I think creates a circular dependency between
uri.hpp and traits/string.hpp.

Thanks for helping,
- Kim

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Kim,

On Fri, Oct 10, 2008 at 8:55 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi guys,
>
> On Thu, Oct 9, 2008 at 20:39, Glyn Matthews <gly...@gm...> wrote:
>>
>> Well it's not really part of the HTTP integration.  And it's not much better
>> doing all development in a single branch than doing it all in trunk.  What I
>> think is best is to develop different tasks in different branches, while
>> testing against trunk.  Ideally, branches should correspond to a
>> task/subproject on the sf site too.
>
> I created a branch succinctly called 'uri', on
> https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri
>
> I've committed the first fumbling parts there, in
> /boost/network/uri.hpp and /libs/network/test/uri_test.hpp.
>

Quick question: where did you branch from? trunk or http_integration?

> At least it's a start, not sure where to go from there...
>
> I didn't parameterize the string type mainly because the default tag
> is under network/protocol/http, and the URI goes one level up in the
> hierarchy, but I suppose I could introduce a temporary tag to wrap the
> string typedef.
>

That raises a good issue though: should we have a single place to have
the tags hierarchy depicted?

I'm thinking:

namespace network {
  struct tags {
    struct http {
      struct message {
        struct tag { };
      };
      // ...
    };
    struct message {
      struct tag { };
    };
    // ...
  };
}

That way we can build traits on top of this hierarchy under a
different namespace 'traits':

namespace network { namespace traits {
  template <class Tag> string;
  template <class Tag> buffer;
  template <class Tag> ostringstream;
  template <class Tag> char_;
  // ...
} }

And specialize them as necessary as well?

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Glyn,

On Thu, Oct 9, 2008 at 4:07 PM, Glyn Matthews <gly...@gm...> wrote:
> Hi Dean,
>
> 2008/10/9 Dean Michael Berris <mik...@gm...>
>>
>> Hey Guys!
>>
>> Sorry I was out for a bit. Personal health issues aside, I should be
>> back on track.
>
> OK, good :)  I hope you're better already.
>

Thanks. :)

>> If we can do it real soon (along with fixing the Python server tests)
>> maybe 0.3 will be a more jam-packed release than what I originally
>> envisioned. ;-)
>
> Do you have a plan for 0.3?
>
> * Fixing the tests

I think this is done in http_integration.

> * Updating docs

This is still a TODO for me. :D

> * URI parsing

If Kim has something up in the subversion tree, it might be good to
have it initially merged into trunk. I can then try and merge the URI
parsing parts from trunk to http_integration, use the URI parsing in
the http::request object.

> * anything else?

I'm waiting for a plan of attack for the MIME library, which is
growing more and more interesting as the days go on.

I've also been in contact with a few people who've already been using
the library (release 0.2) and they're growing more and more interested
in:

- how we'll support 1.1
- whether asynchronous body readers will be supported (streaming callbacks)

There's also some insight about mimicking whatever CURL has, but
that's a little too ambitious for us at the moment. :D

HTH!

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Kim,

2008/10/10 Glyn Matthews <gly...@gm...>

> Hi Kim,
>
> 2008/10/10 Kim Gräsman <kim...@gm...>
>
>>
>> I created a branch succinctly called 'uri', on
>> https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri
>>
>> I've committed the first fumbling parts there, in
>> /boost/network/uri.hpp and /libs/network/test/uri_test.hpp.
>>
>> At least it's a start, not sure where to go from there...
>>
>
> Thanks.  I'll take a look when I have time over the weekend.
>


I've taken a look, and the tests seem OK.  It didn't compile on GCC because
you'd left all the typenames in, but I did a bit of refactoring to fix
this.  I made it a template (basic_url) and provided a default typedef.
This is similar to the way we're using basic_message, so it's more
consistent.  I think for basic_message and basic_url, it would eventually be
necessary to refactor the traits because they will have a lot in common.

I've added a single unit test case which will test the syntax we discussed.
The next stage will be to develop the directives to make this work.

HTH,
Glyn

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Kim,

2008/10/10 Kim Gräsman <kim...@gm...>

>
> I created a branch succinctly called 'uri', on
> https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri
>
> I've committed the first fumbling parts there, in
> /boost/network/uri.hpp and /libs/network/test/uri_test.hpp.
>
> At least it's a start, not sure where to go from there...
>

Thanks.  I'll take a look when I have time over the weekend.
Glyn

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi guys,

On Thu, Oct 9, 2008 at 20:39, Glyn Matthews <gly...@gm...> wrote:
>
> Well it's not really part of the HTTP integration.  And it's not much better
> doing all development in a single branch than doing it all in trunk.  What I
> think is best is to develop different tasks in different branches, while
> testing against trunk.  Ideally, branches should correspond to a
> task/subproject on the sf site too.

I created a branch succinctly called 'uri', on
https://cpp-netlib.svn.sourceforge.net/svnroot/cpp-netlib/branches/uri

I've committed the first fumbling parts there, in
/boost/network/uri.hpp and /libs/network/test/uri_test.hpp.

At least it's a start, not sure where to go from there...

I didn't parameterize the string type mainly because the default tag
is under network/protocol/http, and the URI goes one level up in the
hierarchy, but I suppose I could introduce a temporary tag to wrap the
string typedef.

- Kim

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Kim,

2008/10/9 Kim Gräsman <kim...@gm...>

> Hi Glyn,
>
> On Thu, Oct 9, 2008 at 10:08, Glyn Matthews <gly...@gm...>
> wrote:
> >
> > Can you create a branch from trunk for this, so we can follow your
> updates?
>
> How about the http_integration branch? That's where I am at the
> moment... I can just check in the uri and uri_tests without
> integrating with the rest of the code, if you want.
>

Well it's not really part of the HTTP integration.  And it's not much better
doing all development in a single branch than doing it all in trunk.  What I
think is best is to develop different tasks in different branches, while
testing against trunk.  Ideally, branches should correspond to a
task/subproject on the sf site too.
G

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Glyn,

On Thu, Oct 9, 2008 at 10:08, Glyn Matthews <gly...@gm...> wrote:
>
> Can you create a branch from trunk for this, so we can follow your updates?

How about the http_integration branch? That's where I am at the
moment... I can just check in the uri and uri_tests without
integrating with the rest of the code, if you want.

- K

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Kim,

2008/10/9 Kim Gräsman <kim...@gm...>

>
> I've already factored this out into a simplistic uri class, but no
> directive support yet.
>
> Not sure I can cook anything up with any speed, but I'm experimenting...
>

Can you create a branch from trunk for this, so we can follow your updates?
Ta,
Glyn

Re: [cpp-netlib-devel] URI processing (Was Re: Work Left)

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

Hi Dean,

2008/10/9 Dean Michael Berris <mik...@gm...>

> Hey Guys!
>
> Sorry I was out for a bit. Personal health issues aside, I should be
> back on track.
>

OK, good :)  I hope you're better already.

If we can do it real soon (along with fixing the Python server tests)
> maybe 0.3 will be a more jam-packed release than what I originally
> envisioned. ;-)
>

Do you have a plan for 0.3?

* Fixing the tests
* Updating docs
* URI parsing
* anything else?

Glyn

Re: [cpp-netlib-devel] Python server tests (Was: URI processing)

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

Hi Dean,

On Thu, Oct 9, 2008 at 09:13, Dean Michael Berris
<mik...@gm...> wrote:
>>
>> I thought the Python tests were working on Linux now -- what's failing?
>>
>
> I wasn't aware there was progress on this front, forgive me. Nope,
> nothing's failing. I should merge this and some documentation changes
> real soon to trunk.

Yay, I'm glad it works. There was some issue with permissions as well,
I think I'll try and figure something out to solve that automatically.

- Kim

Re: [cpp-netlib-devel] Python server tests (Was: URI processing)

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

On Thu, Oct 9, 2008 at 3:04 PM, Kim Gräsman <kim...@gm...> wrote:
> Hi Dean,
>
> Quick one first;
>
> On Thu, Oct 9, 2008 at 00:25, Dean Michael Berris
> <mik...@gm...> wrote:
>>
>> If we can do it real soon (along with fixing the Python server tests)
>> maybe 0.3 will be a more jam-packed release than what I originally
>> envisioned. ;-)
>
> I thought the Python tests were working on Linux now -- what's failing?
>

I wasn't aware there was progress on this front, forgive me. Nope,
nothing's failing. I should merge this and some documentation changes
real soon to trunk.

0.3 here we come...

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.