Menu
▾
▴
cpp-netlib-devel — Developers Mailing List
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(52) |
Jun
(30) |
Jul
(17) |
Aug
(9) |
Sep
(4) |
Oct
(7) |
Nov
(11) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
|
Feb
(1) |
Mar
(37) |
Apr
(28) |
May
(15) |
Jun
(28) |
Jul
(7) |
Aug
(125) |
Sep
(116) |
Oct
(85) |
Nov
(14) |
Dec
(6) |
| 2009 |
Jan
(11) |
Feb
(4) |
Mar
(5) |
Apr
|
May
(9) |
Jun
(5) |
Jul
(4) |
Aug
(40) |
Sep
(1) |
Oct
(19) |
Nov
(43) |
Dec
(45) |
| 2010 |
Jan
(76) |
Feb
(95) |
Mar
(3) |
Apr
(23) |
May
(39) |
Jun
(54) |
Jul
(6) |
Aug
(13) |
Sep
(12) |
Oct
(59) |
Nov
(53) |
Dec
(43) |
| 2011 |
Jan
(43) |
Feb
(44) |
Mar
(25) |
Apr
(23) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(6) |
Oct
|
Nov
|
Dec
|
|
From: Dean M. B. <mik...@gm...> - 2008-10-22 07:22:35
|
Hi Kim, On Tue, Oct 21, 2008 at 8:48 PM, Kim Gräsman <kim...@gm...> wrote: > Hi Dean, > > On Tue, Oct 21, 2008 at 12:27, Dean Michael Berris > <mik...@gm...> wrote: >> >> Okay. Can you try integrating (i.e. merging your changes) with >> http_integration to make the request object use the refactored URI >> implementation? > > I tried, but I got stuck in the tag/traits confusion again. The traits > associated with boost::network::http::message_tag are named > differently from the ones bundled with boost::network::tags::default_, > so when I try to use the basic_request tag with basic_uri, > ostringstream's type is no longer available. > > I tried adding a specialization in boost::network::http called > ostringstream, but the compiler lets me know that "symbol cannot be > defined within namespace 'http'", presumably because it's defined in > boost::network already. > Right. Try specializing ostringstream in boost::network and specialize it for boost::network::http::message_tag and see if that works? Or, if you're up for it, you can rename the traits for boost::network::http::message_tag to look like the traits used for boost::network::tags::default_. ;-) HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-10-21 13:31:25
|
Hi Glyn, On Tue, Oct 21, 2008 at 14:23, Glyn Matthews <gly...@gm...> wrote: > >> There were also some implicit assumptions that the URI was for HTTP, >> with path normalization, etc. I've removed that, so that clients will >> need to translate empty path to "/" if necessary, and the same with >> the port number. > > Do you still intend to keep the host/port in the fusion map? How do you > intend to deal with URIs like this: > > file:///home/user/myfile.txt > mailto:som...@ex... Yeah, I've been wondering the same thing lately... I'm afraid to even suggest subtyping of some kind :-) >From what I've gathered from the RFC and other places, everything after the scheme prefix is scheme-specific, so I don't know if it makes sense to try and parse differently-schemed URIs the same way at all. - Kim |
|
From: Glyn M. <gly...@gm...> - 2008-10-21 12:53:44
|
Hi Kim, 2008/10/21 Kim Gräsman <kim...@gm...> > > I've gone back and forth between fusion::map and regular members, but > after Dean's suggestions that there are indeed benefits in the fusion > map, I've gone back to the original layout. > > There were also some implicit assumptions that the URI was for HTTP, > with path normalization, etc. I've removed that, so that clients will > need to translate empty path to "/" if necessary, and the same with > the port number. > Do you still intend to keep the host/port in the fusion map? How do you intend to deal with URIs like this: file:///home/user/myfile.txt mailto:som...@ex... ? Or haven't you got that far yet? ;) G |
|
From: K. G. <kim...@gm...> - 2008-10-21 12:48:55
|
Hi Dean, On Tue, Oct 21, 2008 at 12:27, Dean Michael Berris <mik...@gm...> wrote: > > Okay. Can you try integrating (i.e. merging your changes) with > http_integration to make the request object use the refactored URI > implementation? I tried, but I got stuck in the tag/traits confusion again. The traits associated with boost::network::http::message_tag are named differently from the ones bundled with boost::network::tags::default_, so when I try to use the basic_request tag with basic_uri, ostringstream's type is no longer available. I tried adding a specialization in boost::network::http called ostringstream, but the compiler lets me know that "symbol cannot be defined within namespace 'http'", presumably because it's defined in boost::network already. Ugh. Time to wake my daghter... - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-10-21 10:27:52
|
Hi Kim, On Tue, Oct 21, 2008 at 6:22 PM, Kim Gräsman <kim...@gm...> wrote: > Hi guys, > > Rev. 114 in the uri branch contains enough directive support to pass > the test Glyn added (i.e. directives path and query_param). > Nice, I'll try and take a look as soon as I get time to do that. > I've gone back and forth between fusion::map and regular members, but > after Dean's suggestions that there are indeed benefits in the fusion > map, I've gone back to the original layout. > > There were also some implicit assumptions that the URI was for HTTP, > with path normalization, etc. I've removed that, so that clients will > need to translate empty path to "/" if necessary, and the same with > the port number. > Okay. Can you try integrating (i.e. merging your changes) with http_integration to make the request object use the refactored URI implementation? > Hope that helps, Sure does, thanks Kim! -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-10-21 10:22:53
|
Hi guys, Rev. 114 in the uri branch contains enough directive support to pass the test Glyn added (i.e. directives path and query_param). I've gone back and forth between fusion::map and regular members, but after Dean's suggestions that there are indeed benefits in the fusion map, I've gone back to the original layout. There were also some implicit assumptions that the URI was for HTTP, with path normalization, etc. I've removed that, so that clients will need to translate empty path to "/" if necessary, and the same with the port number. Hope that helps, - Kim |
|
From: Glyn M. <gly...@gm...> - 2008-10-20 17:57:13
|
OK, it's done. If there are any further problems, let me know. G 2008/10/20 Glyn Matthews <gly...@gm...> > Hi, > > 2008/10/20 Dean Michael C. Berris <dmb...@fr...> > >> Hi Glyn, >> >> Yes, please make this 0.3 :) > > > OK, good, but it'll have to wait till I get home this evening. > G > > > |
|
From: Glyn M. <gly...@gm...> - 2008-10-20 08:44:06
|
Hi, 2008/10/20 Dean Michael C. Berris <dmb...@fr...> > Hi Glyn, > > Yes, please make this 0.3 :) OK, good, but it'll have to wait till I get home this evening. G |
|
From: K. G. <kim...@gm...> - 2008-10-20 06:05:30
|
Hi Dean, On Mon, Oct 20, 2008 at 06:50, Dean Michael Berris <mik...@gm...> wrote: > > On Sun, Oct 19, 2008 at 4:14 PM, Kim Gräsman <kim...@gm...> wrote: >> >> I'm looking at the URI processing again, and I don't really see the >> benefit of the Fusion map. Is Fusion required by the Spirit parser? Or >> just the easiest way to export the parser results? >> > > Actually, there's something here that's not terribly obvious. > > One thing that isn't there yet (that ought to be) is the normalization > of values in the fusion map, using fusion algorithms, that get > unrolled at compile time by any compiler. ;) > > So instead of doing a run-time loop for compile-time unrollable loops > (for example, lower-casing any protocols, making sure domain names are > lower-cased, URL-encoding parameters, etc.) we get the efficiency with > a nice and expressive yet succinct syntax. I figured there was something like that, thanks! - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-10-20 04:51:12
|
Hi Kim, On Sun, Oct 19, 2008 at 4:14 PM, Kim Gräsman <kim...@gm...> wrote: > Hello, > > I'm looking at the URI processing again, and I don't really see the > benefit of the Fusion map. Is Fusion required by the Spirit parser? Or > just the easiest way to export the parser results? > Actually, there's something here that's not terribly obvious. One thing that isn't there yet (that ought to be) is the normalization of values in the fusion map, using fusion algorithms, that get unrolled at compile time by any compiler. ;) So instead of doing a run-time loop for compile-time unrollable loops (for example, lower-casing any protocols, making sure domain names are lower-cased, URL-encoding parameters, etc.) we get the efficiency with a nice and expressive yet succinct syntax. > If it's possible to extract the parser matches to regular variables, I > figure a couple of regular data members would be simpler. > That's the naive approach, which although may work, will lead to a lot of problems later once we add more parts of the URI that need to be processed similar to the other parts (lower-casing, widening/shortening, URL-encoding, etc.). > Is there any benefit of the Fusion map that I don't see? Perhaps the above explanation (with lack code sample still) can help. HTH -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Dean M. C. B. <dmb...@fr...> - 2008-10-20 04:36:20
|
Hi Glyn, Yes, please make this 0.3 :) Thanks very much for this! :D -- Dean Michael Berris Software Engineer, Friendster, Inc. > -----Original Message----- > From: Glyn Matthews [mailto:gly...@gm...] > Sent: Monday, October 20, 2008 2:17 AM > To: C++ Networking Library Developers Mailing List > Subject: [cpp-netlib-devel] Release 0.3 > > Dean, > > > I've updated some of the docs and merged http_integration and > docs to trunk. If nothing else is wrong, can we make this 0.3? > > > Glyn > > > |
|
From: Glyn M. <gly...@gm...> - 2008-10-19 18:17:32
|
Dean, I've updated some of the docs and merged http_integration and docs to trunk. If nothing else is wrong, can we make this 0.3? Glyn |
|
From: K. G. <kim...@gm...> - 2008-10-19 08:14:30
|
Hello, I'm looking at the URI processing again, and I don't really see the benefit of the Fusion map. Is Fusion required by the Spirit parser? Or just the easiest way to export the parser results? If it's possible to extract the parser matches to regular variables, I figure a couple of regular data members would be simpler. Is there any benefit of the Fusion map that I don't see? Thanks, - Kim |
|
From: Glyn M. <gly...@gm...> - 2008-10-17 18:42:19
|
Hi Dean, thanks for the quick response. 2008/10/17 Dean Michael Berris <mik...@gm...> > Hi Glyn! > > > Dean: is this intended to be part of the next release? Do you have a > time > > frame for this? > > Yes, it should be part of the next release. Unfortunately, the day job > is taking a lot more of my time and this has hit the back-burner for > me again. :( > > Glyn, can you please do the merge and if you can as well update the > documentation regarding the new functions and files (client_fwd.hpp > for http)? This would be greatly appreciated. > Yeah, I'll do this over the weekend. > > Thanks for the great work guys, it's getting to a point where we can > really start flaunting this software soon. :) A few more test and a > few more features and we should be on-track to packaging a new release > with (gasp) HTTP 1.1 client support. :D > > (I'll bug some people here so that I can release the HTTP Server as > open source as well. I hope that turns out better for a lot of people > and brings us closer to 1.0) :) Do you have more information on this? It sounds interesting :) G |
|
From: Dean M. B. <mik...@gm...> - 2008-10-17 18:29:34
|
Hi Glyn! On Sat, Oct 18, 2008 at 2:19 AM, Glyn Matthews <gly...@gm...> wrote: > Hi Kim, > > 2008/10/17 Kim Gräsman <kim...@gm...> >> >> I just committed a significantly cleaned up version of >> http_test_server.hpp, that uses Boost.Filesystem as you suggested. >> >> Also, Python 2.6 has just been released, and our excluded test case >> works fine with it, so I re-included it. >> >> >>> Maybe you'd like to try out using Virtualbox to install a Linux distro >> >>> (of your choice, I prefer Ubuntu for development) on a few GB's worth >> >>> of disk space? That's what I do at least to be able to try things out >> >>> in Linux. ;-) >> >> I got Ubuntu up and running in a Virtualbox, and have tested the >> changes there. Everything seems to work! > > Great. It works on my non-virtual ubuntu installation too ;) > > Dean: is this intended to be part of the next release? Do you have a time > frame for this? Yes, it should be part of the next release. Unfortunately, the day job is taking a lot more of my time and this has hit the back-burner for me again. :( Glyn, can you please do the merge and if you can as well update the documentation regarding the new functions and files (client_fwd.hpp for http)? This would be greatly appreciated. Thanks for the great work guys, it's getting to a point where we can really start flaunting this software soon. :) A few more test and a few more features and we should be on-track to packaging a new release with (gasp) HTTP 1.1 client support. :D (I'll bug some people here so that I can release the HTTP Server as open source as well. I hope that turns out better for a lot of people and brings us closer to 1.0) :) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Glyn M. <gly...@gm...> - 2008-10-17 18:19:32
|
Hi Kim, 2008/10/17 Kim Gräsman <kim...@gm...> > I just committed a significantly cleaned up version of > http_test_server.hpp, that uses Boost.Filesystem as you suggested. > > Also, Python 2.6 has just been released, and our excluded test case > works fine with it, so I re-included it. > > >>> Maybe you'd like to try out using Virtualbox to install a Linux distro > >>> (of your choice, I prefer Ubuntu for development) on a few GB's worth > >>> of disk space? That's what I do at least to be able to try things out > >>> in Linux. ;-) > > I got Ubuntu up and running in a Virtualbox, and have tested the > changes there. Everything seems to work! > Great. It works on my non-virtual ubuntu installation too ;) Dean: is this intended to be part of the next release? Do you have a time frame for this? G |
|
From: K. G. <kim...@gm...> - 2008-10-17 12:36:39
|
Hi Dean, On Tue, Oct 14, 2008 at 15:05, Dean Michael Berris <mik...@gm...> wrote: > > Okay. After a visual inspection, I'd rather we not do it this way. If > you would like to use Boost.Filesystem, that would be nice and more > platform-independent as far as dealing with directories and file > names. I just committed a significantly cleaned up version of http_test_server.hpp, that uses Boost.Filesystem as you suggested. Also, Python 2.6 has just been released, and our excluded test case works fine with it, so I re-included it. >>> Maybe you'd like to try out using Virtualbox to install a Linux distro >>> (of your choice, I prefer Ubuntu for development) on a few GB's worth >>> of disk space? That's what I do at least to be able to try things out >>> in Linux. ;-) I got Ubuntu up and running in a Virtualbox, and have tested the changes there. Everything seems to work! - Kim |
|
From: K. G. <kim...@gm...> - 2008-10-14 13:34:19
|
Hi Dean, On Tue, Oct 14, 2008 at 15:24, Dean Michael Berris <mik...@gm...> wrote: > And while I was at it, I decided to check in the fix I was comfortable > of doing as far as the testing is concerned. It's available in > http_integration. Cool, thanks. > I'm merging that branch to trunk soon, then updating the documentation for 0.3. > > Is the URI implementation ready for the merge too? Not really, I don't think we should let that work hold back the merge and release. - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-10-14 13:25:08
|
And while I was at it, I decided to check in the fix I was comfortable of doing as far as the testing is concerned. It's available in http_integration. I'm merging that branch to trunk soon, then updating the documentation for 0.3. Is the URI implementation ready for the merge too? On Tue, Oct 14, 2008 at 9:05 PM, Dean Michael Berris <mik...@gm...> wrote: ... -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: Dean M. B. <mik...@gm...> - 2008-10-14 13:05:57
|
On Tue, Oct 14, 2008 at 8:56 PM, Kim Gräsman <kim...@gm...> wrote: > > On Tue, Oct 14, 2008 at 14:31, Dean Michael Berris > <mik...@gm...> wrote: >>> >>> However, since I don't have a Linux environment, I can't really test >>> it (nor build, actually)... So, does anyone feel up for testing that >>> it builds and sets the execute bit on all files in cgi-bin/? >>> >> >> Is this available in the http_integration branch? > > I'm not confident enough of my blind changes to commit them, but > here's a patch with my mods. > Okay. After a visual inspection, I'd rather we not do it this way. If you would like to use Boost.Filesystem, that would be nice and more platform-independent as far as dealing with directories and file names. For the meantime just chmod'ing the files by name should be alright. >> Maybe you'd like to try out using Virtualbox to install a Linux distro >> (of your choice, I prefer Ubuntu for development) on a few GB's worth >> of disk space? That's what I do at least to be able to try things out >> in Linux. ;-) > > I'll see if I can free a couple of gigs and experiment. Might be a > nice learning experience as well :) > I think it will. :D -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-10-14 12:56:52
|
Hi Dean, On Tue, Oct 14, 2008 at 14:31, Dean Michael Berris <mik...@gm...> wrote: >> >> However, since I don't have a Linux environment, I can't really test >> it (nor build, actually)... So, does anyone feel up for testing that >> it builds and sets the execute bit on all files in cgi-bin/? >> > > Is this available in the http_integration branch? I'm not confident enough of my blind changes to commit them, but here's a patch with my mods. > Maybe you'd like to try out using Virtualbox to install a Linux distro > (of your choice, I prefer Ubuntu for development) on a few GB's worth > of disk space? That's what I do at least to be able to try things out > in Linux. ;-) I'll see if I can free a couple of gigs and experiment. Might be a nice learning experience as well :) Cheers, - Kim |
|
From: Dean M. B. <mik...@gm...> - 2008-10-14 12:31:35
|
Hi Kim, On Tue, Oct 14, 2008 at 6:39 PM, Kim Gräsman <kim...@gm...> wrote: > > However, since I don't have a Linux environment, I can't really test > it (nor build, actually)... So, does anyone feel up for testing that > it builds and sets the execute bit on all files in cgi-bin/? > Is this available in the http_integration branch? Maybe you'd like to try out using Virtualbox to install a Linux distro (of your choice, I prefer Ubuntu for development) on a few GB's worth of disk space? That's what I do at least to be able to try things out in Linux. ;-) -- Dean Michael C. Berris Software Engineer, Friendster, Inc. |
|
From: K. G. <kim...@gm...> - 2008-10-14 10:39:15
|
Hi all, Someone (Divye?) suggested that the python HTTP server requires execute permissions in the cgi-bin directory, and I can see how that makes sense. The http_test_server.hpp code contained a little snippet that did chmod on cgi-bin/requestinfo.py, but since we have a few more cgi-bin scripts now, I've tried to generalize that to run the same chmod on all files inside cgi-bin. However, since I don't have a Linux environment, I can't really test it (nor build, actually)... So, does anyone feel up for testing that it builds and sets the execute bit on all files in cgi-bin/? Thanks, - Kim |
|
From: K. G. <kim...@gm...> - 2008-10-13 13:11:45
|
Hi guys, On Mon, Oct 13, 2008 at 14:39, Dean Michael Berris <mik...@gm...> wrote: > > Why not use tags::default_ like basic_message? I just committed a new version in the uri branch with the uri folder removed, and where uri_fwd.hpp and uri.hpp use the message traits, as suggested above. I also moved the parser tags back into uri, I didn't think they needed to be exposed outside of the class. - Kim |
|
From: K. G. <kim...@gm...> - 2008-10-13 13:06:12
|
Hey there,
On Mon, Oct 13, 2008 at 14:57, Dean Michael Berris
<mik...@gm...> wrote:
>
>> 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
Ah, I see. Yeah, that makes sense.
As all the default cases were left with a variation of
template <class Tag>
struct string {
typedef void type;
};
, I didn't see that coming. But sure, if the default actually defines
defaults, everything will be dandy! :)
- Kim
|
7 messages has been excluded from this view by a project administrator.
