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...> - 2010-01-29 23:47:58
|
Hi Everyone, I've just bundled and released cpp-netlib v0.5 on Sourceforge and Github. You can check the wonderful work of Glyn over at http://cpp-netlib.github.com/ as well as download the release from http://github.com/cpp-netlib/cpp-netlib/downloads -- please file issues found over at http://github.com/cpp-netlib/cpp-netlib/issues . We should be starting conversations around what we should be releasing by the end of February (0.6). I'm personally looking into a more robust and extensible HTTP Server template implementation as well as some helper utility libraries for server-side REST service development. If you have feature requests and or suggestions and comments they would very much be welcome. Thanks to everyone who contributed to the effort and making this 0.5 release on target and successful. Have a great weekend everyone and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-01-25 19:54:44
|
Hi Erik, 2010/1/25 Nelson, Erik - 2 <eri...@ba...> > Dean Michael Berris wrote: > > It would be cool if we used the Github issue tracker instead for > > things like these. ;) > > I've never used Github... I need to get that figured out. > It's very straightforward to use the issue tracker, simply go to http://github.com/mikhailberis/cpp-netlib/issues and you'll be able to create an issue there. G |
|
From: Dean M. B. <mik...@gm...> - 2010-01-25 19:39:58
|
On Tue, Jan 26, 2010 at 3:37 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: >> It would be cool if we used the Github issue tracker instead for >> things like these. ;) > > I've never used Github... I need to get that figured out. > It might be a good idea to start now. ;) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-25 19:38:11
|
Dean Michael Berris wrote: > It would be cool if we used the Github issue tracker instead for > things like these. ;) I've never used Github... I need to get that figured out. |
|
From: Dean M. B. <mik...@gm...> - 2010-01-23 15:06:39
|
On Sat, Jan 23, 2010 at 7:42 PM, Glyn Matthews <gly...@gm...> wrote: > > > Perhaps, but I still think that the point you bring up is a valid one. > > I added a wiki page @ > http://wiki.github.com/glynos/cpp-netlib/c-network-library-style-guidelines > in any case. This will eventually cover some broad aspects such as > directory/namespace structure and stuff about tags/traits and concepts where > consistency matters. > This makes sense and somehow I feel like I should be the one writing this document. ;) Or at least I should be leading the discussion. :D Up to this point I haven't found the need to write down the conventions I use in the code though so it would be good to follow a set of guidelines so that we can somehow bring some order into the "chaos". :D Thanks for doing this Glyn! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Glyn M. <gly...@gm...> - 2010-01-23 11:42:26
|
On 22 January 2010 20:33, Nelson, Erik - 2 <eri...@ba...>wrote: > Glyn Matthews wrote: > > > The coding style sometimes bothers me too (not so much curly braces > placement as indenting), > > but I get that all the time when I look at other people's code ;) If > you think its a going to be a hindrance > > then perhaps we could open a discussion about guidelines. > > > Maybe consistency would be important at least, because this project > could potentially > > be large and the nature of the design doesn't lend itself to highly > readable code. > > I'm with you- I only like my own code. And if I haven't read my own code > for a while, then I don't even like my own code. :) > > I don't have any interest in a discussion... you guys are doing the work. > My parents always told me to never complain when someone else is working and > I am benefitting. > Perhaps, but I still think that the point you bring up is a valid one. I added a wiki page @ http://wiki.github.com/glynos/cpp-netlib/c-network-library-style-guidelinesin any case. This will eventually cover some broad aspects such as directory/namespace structure and stuff about tags/traits and concepts where consistency matters. G |
|
From: Dean M. B. <mik...@gm...> - 2010-01-23 08:25:23
|
On Sat, Jan 23, 2010 at 3:20 AM, Glyn Matthews <gly...@gm...> wrote:
> Hi Erik,
>
> 2010/1/22 Nelson, Erik - 2 <eri...@ba...>
>>
>> Thanks for the help... It's working now, and I'm playing with it some
>> more.
>>
>> I'm not sure if it matters, but in connection.hpp, in the connection
>> constructor, there's a bit of code like
>>
>> try {
>> socket_.set_option(tcp::no_delay(true)); // Don't delay
>> writing
>> } catch (system::system_error & e) {
>> handler_.log(e.what());
>> }
>>
>> And the set_option call *always* seems to throw
>> boost::asio::error::bad_descriptor. Not sure if it matters.
>>
This actually matters and is a bug. Thanks for reporting it, it's
issue #5 on GitHub now.
It would be cool if we used the Github issue tracker instead for
things like these. ;)
--
Dean Michael Berris
cplusplus-soup.com | twitter.com/deanberris
linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com
|
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-22 19:42:25
|
Glyn Matthews wrote: > The coding style sometimes bothers me too (not so much curly braces placement as indenting), > but I get that all the time when I look at other people's code ;) If you think its a going to be a hindrance > then perhaps we could open a discussion about guidelines. > Maybe consistency would be important at least, because this project could potentially > be large and the nature of the design doesn't lend itself to highly readable code. I'm with you- I only like my own code. And if I haven't read my own code for a while, then I don't even like my own code. :) I don't have any interest in a discussion... you guys are doing the work. My parents always told me to never complain when someone else is working and I am benefitting. Erik |
|
From: Glyn M. <gly...@gm...> - 2010-01-22 19:20:47
|
Hi Erik,
2010/1/22 Nelson, Erik - 2 <eri...@ba...>
> Thanks for the help... It's working now, and I'm playing with it some
> more.
>
> I'm not sure if it matters, but in connection.hpp, in the connection
> constructor, there's a bit of code like
>
> try {
> socket_.set_option(tcp::no_delay(true)); // Don't delay
> writing
> } catch (system::system_error & e) {
> handler_.log(e.what());
> }
>
> And the set_option call *always* seems to throw
> boost::asio::error::bad_descriptor. Not sure if it matters.
>
> One other thing I noticed (and don't personally care about) is the
> cpp-netlib coding style, like curly brace placement. I'm not sure if
> there are boost coding guidelines or not, or if they are enforced or
> not, but cpp-netlib looks a little different than other boost source
> code. Again, I'm perfectly happy with however it is, but if the goal is
> to move cpp-netlib into boost and boost cares (I don't know that either
> of those assumptions are true), it's probably easier to start doing it
> "the boost way" sooner rather than later.
>
>
There isn't really a "boost way", I think, the closest it gets is in the
guidelines:
http://www.boost.org/development/requirements.html
But that stops short of specifying how the source code should be formatted,
but focuses on portability and license issues. Different boost libraries
seem to be formatted differently, depending on each author's preferences.
The coding style sometimes bothers me too (not so much curly braces
placement as indenting), but I get that all the time when I look at other
people's code ;) If you think its a going to be a hindrance then perhaps we
could open a discussion about guidelines.
Maybe consistency would be important at least, because this project could
potentially be large and the nature of the design doesn't lend itself to
highly readable code.
Glyn
|
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-22 19:03:48
|
Thanks for the help... It's working now, and I'm playing with it some
more.
I'm not sure if it matters, but in connection.hpp, in the connection
constructor, there's a bit of code like
try {
socket_.set_option(tcp::no_delay(true)); // Don't delay
writing
} catch (system::system_error & e) {
handler_.log(e.what());
}
And the set_option call *always* seems to throw
boost::asio::error::bad_descriptor. Not sure if it matters.
One other thing I noticed (and don't personally care about) is the
cpp-netlib coding style, like curly brace placement. I'm not sure if
there are boost coding guidelines or not, or if they are enforced or
not, but cpp-netlib looks a little different than other boost source
code. Again, I'm perfectly happy with however it is, but if the goal is
to move cpp-netlib into boost and boost cares (I don't know that either
of those assumptions are true), it's probably easier to start doing it
"the boost way" sooner rather than later.
Thanks
Erik
|
|
From: Dean M. B. <mik...@gm...> - 2010-01-21 19:06:54
|
On Fri, Jan 22, 2010 at 2:54 AM, Jeroen Habraken <vex...@gm...> wrote: > On Thu, Jan 21, 2010 at 18:39, Dean Michael Berris > <mik...@gm...> wrote: > > Added a couple of issues with patches in github, the one that is > remaining is the discussion on `and` etcetera. > Thanks for those, I see them. I'll apply and test locally before pushing to 0.5-devel. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-21 19:02:13
|
On Thu, Jan 21, 2010 at 18:39, Dean Michael Berris <mik...@gm...> wrote: > On Fri, Jan 22, 2010 at 1:25 AM, Jeroen Habraken <vex...@gm...> wrote: >> On Thu, Jan 21, 2010 at 18:17, Dean Michael Berris >> <mik...@gm...> wrote: >>> >>> Are these patches also on your fork? Those would be good to have >>> merged into the 0.5-devel line soon. >> >> No, they aren't, and I was about to ask. It might be easiest here if I >> create a couple of issues and attach the patches there. >> > > Definitely. Added a couple of issues with patches in github, the one that is remaining is the discussion on `and` etcetera. >>> BTW, are your changes ready to merge into 0.5-devel so I can test locally? >> >> Not really, there is still quite a bit of work to be done as I've >> described in the URI thread, and major functionality like the IP >> parsing is missing. As I have exams at the moment it's hard to tell >> when I have time to work on this. The current code in my fork should >> compile and run though, and I'd like your opinion on the way I >> implemented the derived HTTP class in my fork. >> > > Alright, sure let me take a look and let you know soon enough. :) > >> Also, my code breaks some of the current code, it seems mostly from >> the transition from protocol() to scheme(), so those need to be fixed. >> > > Cool, no worries there. Let me know when you've done these changes on > your branch too and once the tests pass we should be good to go for a > merge. > >> >> Sorry, attached the wrong patch, this one will actually fix the >> documentation and tests. >> > > No problem, thanks for these! > > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-21 17:40:19
|
On Fri, Jan 22, 2010 at 1:25 AM, Jeroen Habraken <vex...@gm...> wrote: > On Thu, Jan 21, 2010 at 18:17, Dean Michael Berris > <mik...@gm...> wrote: >> >> Are these patches also on your fork? Those would be good to have >> merged into the 0.5-devel line soon. > > No, they aren't, and I was about to ask. It might be easiest here if I > create a couple of issues and attach the patches there. > Definitely. >> BTW, are your changes ready to merge into 0.5-devel so I can test locally? > > Not really, there is still quite a bit of work to be done as I've > described in the URI thread, and major functionality like the IP > parsing is missing. As I have exams at the moment it's hard to tell > when I have time to work on this. The current code in my fork should > compile and run though, and I'd like your opinion on the way I > implemented the derived HTTP class in my fork. > Alright, sure let me take a look and let you know soon enough. :) > Also, my code breaks some of the current code, it seems mostly from > the transition from protocol() to scheme(), so those need to be fixed. > Cool, no worries there. Let me know when you've done these changes on your branch too and once the tests pass we should be good to go for a merge. > > Sorry, attached the wrong patch, this one will actually fix the > documentation and tests. > No problem, thanks for these! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-21 17:26:27
|
On Thu, Jan 21, 2010 at 18:17, Dean Michael Berris <mik...@gm...> wrote: > On Fri, Jan 22, 2010 at 1:14 AM, Jeroen Habraken <vex...@gm...> wrote: >> >> It seems I missed two uint32_t's when moving to the uint16_t type for >> ports, I've attached a trivial patch which should fix this. The >> attached patch also updates the documentation and tests. >> > > Are these patches also on your fork? Those would be good to have > merged into the 0.5-devel line soon. No, they aren't, and I was about to ask. It might be easiest here if I create a couple of issues and attach the patches there. > BTW, are your changes ready to merge into 0.5-devel so I can test locally? Not really, there is still quite a bit of work to be done as I've described in the URI thread, and major functionality like the IP parsing is missing. As I have exams at the moment it's hard to tell when I have time to work on this. The current code in my fork should compile and run though, and I'd like your opinion on the way I implemented the derived HTTP class in my fork. Also, my code breaks some of the current code, it seems mostly from the transition from protocol() to scheme(), so those need to be fixed. > -- > Dean Michael Berris > cplusplus-soup.com | twitter.com/deanberris > linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com > Sorry, attached the wrong patch, this one will actually fix the documentation and tests. Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-21 17:18:19
|
On Fri, Jan 22, 2010 at 1:14 AM, Jeroen Habraken <vex...@gm...> wrote: > > It seems I missed two uint32_t's when moving to the uint16_t type for > ports, I've attached a trivial patch which should fix this. The > attached patch also updates the documentation and tests. > Are these patches also on your fork? Those would be good to have merged into the 0.5-devel line soon. BTW, are your changes ready to merge into 0.5-devel so I can test locally? -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Jeroen H. <vex...@gm...> - 2010-01-21 17:14:56
|
Hi, On Thu, Jan 21, 2010 at 17:57, Nelson, Erik - 2 <eri...@ba...> wrote: > In boost/network/uri/http/uri_concept.hpp line 22, I get a warning about > conversion from a 32-bit to 16-bit integer > > 'initializing' : conversion from 'boost::uint32_t' to 'boost::uint16_t', > possible loss of data > > Here's the offending line > > uint16_t port_ = port(uri); > > I'm not sure if it matters (probably doesn't) but if the truncation is > as designed we might consider making it explicit with a cast. > > Thanks > > Erik > It seems I missed two uint32_t's when moving to the uint16_t type for ports, I've attached a trivial patch which should fix this. The attached patch also updates the documentation and tests. Jeroen |
|
From: Dean M. B. <mik...@gm...> - 2010-01-21 17:13:15
|
On Fri, Jan 22, 2010 at 12:00 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: >> It seems that you're using the version in the 'master' branch. Can >> you try the latest from 0.5-devel? > > I'm using the code that I checked out from > > http://github.com/mikhailberis/cpp-netlib/blob/0.5-devel/ > > Is that correct? > Yup, if it's a problem there then a fix would be nice to get. :) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-21 16:57:44
|
Jeroen Habraken wrote: >I've written a patch which might fix the two URI related errors, though I currently have no way of testing them as I have no Windows install around, please give them a shot and let me know. I just took the typedef patch, which worked fine. Thanks much. The other patch was for the and/not/or broken compiler thing, which I fixed temporarily with the include. Whatever the collective decision is about how to solve that in the repository is fine with me- I'll get it when it comes out in 0.5 Thanks Erik |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-21 16:57:43
|
In boost/network/uri/http/uri_concept.hpp line 22, I get a warning about conversion from a 32-bit to 16-bit integer 'initializing' : conversion from 'boost::uint32_t' to 'boost::uint16_t', possible loss of data Here's the offending line uint16_t port_ = port(uri); I'm not sure if it matters (probably doesn't) but if the truncation is as designed we might consider making it explicit with a cast. Thanks Erik |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-21 16:50:31
|
Glyn Matthews wrote: >> 2) the error comes from request_methods.ipp, on line >> static char const * const DELETE = "DELETE"; >> Winnt.h #defines DELETE. If I change the offending line in >> request_methods.ipp to 'DELETE_', that seems to fix it > Can you submit a patch? I've tried a bit to get the git dev tools set up, but the company firewall doesn't allow SSH traffic as far as I can tell, and I haven't managed to figure out how to clone the repository over http. At any rate, in \boost\network\protocol\http\traits\impl\request_methods.ipp I changed static char const * const DELETE = "DELETE"; to static char const * const DELETE_ = "DELETE"; and made the corresponding change to the next line. apologies for the un-handy patch style... I'll try to figure out a better way. Erik |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-21 16:00:22
|
Dean Michael Berris wrote: > It seems that you're using the version in the 'master' branch. Can > you try the latest from 0.5-devel? I'm using the code that I checked out from http://github.com/mikhailberis/cpp-netlib/blob/0.5-devel/ Is that correct? Erik |
|
From: Glyn M. <gly...@gm...> - 2010-01-21 08:31:45
|
2010/1/20 Dean Michael Berris <mik...@gm...> > On Thu, Jan 21, 2010 at 5:46 AM, Glyn Matthews <gly...@gm...> > wrote: > > > > 2010/1/20 Dean Michael Berris <mik...@gm...> > >> > >> > >> This is so cool! I should learn to do this one of these days. :D > > > > Very easy to do, the instructions can be found if you go to a page that > > doesn't exist, like: > > > > http://cpp-netlib.github.com/ > > > > Nice! Thanks I'll look into doing that one of these days. Sure beats > having to do it via SSH on sourceforge IMO. ;) > > >> > >> One quick thing is that the marker image doesn't show -- you may have > >> forgotten to put them images into the appropriate directory. ;) > >> > > > > The links to the marker images are on boost.org, which don't seem to > exist. > > I don't know how to fix this. > > > > Oh, okay. I remember those being part of the quickbook images when you > build the documentation that came with the example. We can host those > images ourselves too. > > >> > >> Thanks again for the great effort on the documentation -- I shall > >> reply in kind soon enough once my consulting work winds down a little. > >> > > OK, thanks. > > BTW, I saw that you sent a pull request already, but it seems you > haven't pulled the latest changes I've made in 0.5-devel into your > fork's 0.5-devel branch. I think there's documentation on how to do > that already available here: http://help.github.com/forking/ -- once > you reconcile the conflicts (if there are any, and it looks like there > will be some because there's quite a number of them commits you have > that failed to apply cleanly) and push back to your fork, I should be > able to pull them cleanly from Github. > > OK, that will have to wait because I can't access Github from work. G |
|
From: Dean M. B. <mik...@gm...> - 2010-01-21 05:43:02
|
On Thu, Jan 21, 2010 at 7:25 AM, Nelson, Erik - 2 <eri...@ba...> wrote: > Dean Michael Berris wrote: >> I think it's because vendors aren't quick to support them natively in >> the compiler. GCC takes this in stride just fine as does other >> vendors (Intel's compiler is another one I know that works pretty >> well). I would quote the appropriate parts of the C++ standard if I >> had a copy (which I promise I should buy someday soon) but anyway >> it's something really annoying to me for non-conformant compilers >> like MSVC. >> >> I also like them better but unfortunately to support more compilers >> we're going to have to stick with !, ||, && et al. > > I'd say just put #include <ciso646> up high and continue to use them. > They are standard C++, and they're much more descriptive than the !&&#|| > stuff. Don't cave in to the noncompliant compiler vendors! > Yeah, I suppose that would work. ;) -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
|
From: Nelson, E. - 2 <eri...@ba...> - 2010-01-20 23:25:29
|
Dean Michael Berris wrote: > I think it's because vendors aren't quick to support them natively in > the compiler. GCC takes this in stride just fine as does other > vendors (Intel's compiler is another one I know that works pretty > well). I would quote the appropriate parts of the C++ standard if I > had a copy (which I promise I should buy someday soon) but anyway > it's something really annoying to me for non-conformant compilers > like MSVC. > > I also like them better but unfortunately to support more compilers > we're going to have to stick with !, ||, && et al. I'd say just put #include <ciso646> up high and continue to use them. They are standard C++, and they're much more descriptive than the !&&#|| stuff. Don't cave in to the noncompliant compiler vendors! Erik |
|
From: Dean M. B. <mik...@gm...> - 2010-01-20 21:54:49
|
On Thu, Jan 21, 2010 at 5:46 AM, Glyn Matthews <gly...@gm...> wrote: > > 2010/1/20 Dean Michael Berris <mik...@gm...> >> >> >> This is so cool! I should learn to do this one of these days. :D > > Very easy to do, the instructions can be found if you go to a page that > doesn't exist, like: > > http://cpp-netlib.github.com/ > Nice! Thanks I'll look into doing that one of these days. Sure beats having to do it via SSH on sourceforge IMO. ;) >> >> One quick thing is that the marker image doesn't show -- you may have >> forgotten to put them images into the appropriate directory. ;) >> > > The links to the marker images are on boost.org, which don't seem to exist. > I don't know how to fix this. > Oh, okay. I remember those being part of the quickbook images when you build the documentation that came with the example. We can host those images ourselves too. >> >> Thanks again for the great effort on the documentation -- I shall >> reply in kind soon enough once my consulting work winds down a little. >> > OK, thanks. BTW, I saw that you sent a pull request already, but it seems you haven't pulled the latest changes I've made in 0.5-devel into your fork's 0.5-devel branch. I think there's documentation on how to do that already available here: http://help.github.com/forking/ -- once you reconcile the conflicts (if there are any, and it looks like there will be some because there's quite a number of them commits you have that failed to apply cleanly) and push back to your fork, I should be able to pull them cleanly from Github. Thanks again and I hope this helps! -- Dean Michael Berris cplusplus-soup.com | twitter.com/deanberris linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com |
7 messages has been excluded from this view by a project administrator.
