Re: [boost] [network] cpp-netlib 0.7 ready to be released

Subject: Re: [boost] [network] cpp-netlib 0.7 ready to be released
From: OvermindDL1 (overminddl1_at_[hidden])
Date: 2010-10-15 19:41:34

On Fri, Oct 15, 2010 at 2:02 PM, Dean Michael Berris
<mikhailberis_at_[hidden]> wrote:
> On Fri, Oct 15, 2010 at 10:32 PM, David Abrahams <dave_at_[hidden]> wrote:
>> At Thu, 14 Oct 2010 23:15:57 +0800,
>> Dean Michael Berris wrote:
>>>
>>> Hi Guys,
>>>
>>> I just wanted to give everyone interested a heads up on the progress
>>> being made on the cpp-netlib project (which I'm working on full-time
>>> at the moment).
>>
>> Awesome! Â Is someone funding that?
>>
>
> Thanks! :)
>
> Nobody is funding this effort now, I'm in between jobs as I type. :D
>
>>> Â * The documentation has been moved from Quickbook to ReStructuredText
>>> and generated with Sphinx (and they look really nice if I may say so
>>> myself: http://mikhailberis.github.com/cpp-netlib/).
>>
>> They do! Â Having not had very much experience with Quickbook, I would
>> be very curious as to what prompted the switch.
>>
>
> Well, not to knock too much on Quickbook, but here are some reasons:
>
> 1. Lack of syntax highlighting support on major editors. I use ViM
> almost exclusively to edit the C++ and the documentation, and it's
> really hard to work on Quickbook docs without the visual cues for
> instant gratification. Of course it's just a matter of writing the
> syntax files, but...
>
> 2. Because of the syntax, it's really hard to write the syntax
> descriptions. I think a real EBNF grammar would work, but regex and
> the syntax files don't do so well. I've tried and gave up multiple
> times in this regard, having contributed syntax highlighting for Kate
> a loooong time ago. I think it's as much a problem with ViM as it is
> with the (nice, but unique) syntax of quickbook documents.
>
> 3. The toolchain is really pretty obscure. If you want to get anywhere
> near changing the layout you're going to have to learn XSLT which is
> so far removed from HTML that it's discouraging. Then there's FOP for
> the PDF, there's BoostBook which are the extension to DocBook, and ...
> well, compared to RST which is very well supported by just the
> docutils package in Python, there's just much less intellectual and
> toolchain baggage to deal with.
>
> 4. RST looks good stand-alone. Quickbook is a lot like a markup
> language, and the documentation tends to look like a program of sorts.
> Sure there's automatic indentation, automatic paragraphs, blurb
> support, the works... but when you read an RST document, you don't
> need it rendered to get the visual cues as to what the structure of
> the document is like.
>
> So I guess I did knock on Quickbook quite a bit. :D
>
>> I also think you should know that there's a
>> slightly-crude-but-very-effective literate programming system for ReST
>> in Boost, under boost/tools/litre/. Â You can see it in use for the
>> Boost.Parameter library. Â We also used that to check all the code in
>> the C++TMP book.
>>
>
> Ooooooh, nice! I'll definitely check this out, thanks for the pointer Dave!
>
>>> This impending 0.7 release also uses more template metaprogramming
>>> tools from Boost.MPL to implement the tag dispatch mechanism to modify
>>> behaviors of the classes based on these tags.
>>
>> Does that show up in the library's interface?
>>
>
> Not one bit. :)
>
> The tag dispatch mechanism is an internal mechanism used by the
> library, similar to how Fusion uses tag dispatch for customization and
> extension. In cpp-netlib though, this is everywhere except in the user
> interface.
>
> Without looking at the internals of cpp-netlib, users shouldn't care
> whether it uses Boost.MPL. It actually didn't for a while until 0.7,
> which is going to come out real soon now. :)
>
>>>
>>> The development of cpp-netlib targets an end-of-year submission to the
>>> Boost Library, and hopefully those interested in the project can go
>>> ahead and try it out now so that I and the other developers can work
>>> on feature requests before that time -- and so that early evaluations
>>> can guide the direction of the development before December.
>>>
>>> Thanks everyone and I look forward to hearing from you!
>>>
>>> Note: You can find the documentation for cpp-netlib (which I presented
>>> at BoostCon 2010) at http://mikhailberis.github.com/cpp-netlib
>>
>> Having something like this in Boost is long overdue, so I'm really
>> looking forward to the results!
>>
>
> Cool, thanks Dave. I'll keep everyone updated as I make progress. :)

I am quite interested in this as well, but I do have three questions.

Currently I use Wt C++ Web Toolkit for a little web interface into a
server of mine, but I would love to drop it due to its extremely nasty
GPL license (so I could then freely give away my code, GPL is *SO*
restrictive..), I mainly use it for three reasons (as I had written a
mini-http server in the past and used that, but this functionality is
just *so* useful and irritating enough to write that I did not want to
add it to mine), and from looking in the docs I do not see this
functionality in there.

First, keeping a socket open.  Just based on what I see in the docs
and examples (which is no doubt incomplete right now anyway, but I
need to know), it does not seem possible to keep a socket open, such
as what I use that for is I send a webpage to a client, but I keep it
open using http chunked encoding and I send javascript bits as
updates, which the browser then runs to update the page, so I send
real-time updates without any need for polling, Wt makes this aspect
quite literally brainless (do whatever work you need to in a thread,
when you need to update some views, grab the lock for a Wt Application
session, update the session, release the lock, which then ripples the
changes to the page in real-time + ping-time, can also just do
something  basic like render part of a page while you do more
processing and just send more of it as processing completes to give
progress updates).

Second, WebSocket/etc... support, this is dependent on the above, need
to keep a socket open, you can 'emulate' it with polling, but that can
cause delayed data, it can cause too much data to be sent when there
are no updates needed, etc...  As stated, I use this type of
functionality to send real-time updates of the server and what is
happening to the webpage, and there are a lot of updates (and thanks
to how Wt works, it only sends updates to things that are visible,
vastly reduces data transmission usage).

Third, I am a programmer, hence I am lazy, I do not want to write a
crap-ton of HTML and Javascript (my main reason for moving to Wt from
my own HTTP built-in server).  Will there be an interface built on top
of cpp-netlib to simplify that?  For example I can write a webpage in
Wt using an interface that is pretty identical to Qt, feels just like
writing a GUI, something I am familiar with and it keeps me nicely in
the domain to which I am accustomed (C++).  I can of course drop out
to sending html (or html chunks) and/or javascript things (of which I
can nicely integrate into a C++ callback on the server side).  I can
setup a Wt 'gui', of which I can stuff my data and server information
in to as updates occur (sometimes very rapidly, sometimes not), and it
just works in every browser, whether javascript is enabled or not
(although if not it falls back to http polling so is a bit slower, but
still works).  Understandably this one may be beyond the scope of
cpp-netlib as-is, but it still needs to be possible to implement such
a thing on it, and perhaps be included with it later on.

Basically what I would use this for in the immediate future is to put
as a simple html interface to a server of mine, using a license that
actually lets me distribute it, without me needing to rewrite some of
the more complicated internals of Wt elsewhere.