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

Subject: Re: [boost] [network] cpp-netlib 0.7 ready to be released
From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2010-10-15 21:08:43

On Sat, Oct 16, 2010 at 7:41 AM, OvermindDL1 <overminddl1_at_[hidden]> wrote:
> On Fri, Oct 15, 2010 at 2:02 PM, Dean Michael Berris
> <mikhailberis_at_[hidden]> wrote:
>
> I am quite interested in this as well, but I do have three questions.
>

Cool. :)

> 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).
>

With the coming 0.7 release, this is not yet possible (keeping the
socket open). However, the 0.8 version will address these and much
more issues with the server implementation.

One of the things that needs to be addressed from the server end is
how to effectively do chunked transfer encoding transparently. This is
going to be a standalone component, yes, but it will have to be
integrated with how an HTTP Connection is implemented in cpp-netlib so
will be intimately tied to how that happens.

> 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).
>

I've been contemplating on making this part of cpp-netlib, but I have
yet to feel good enough about the specifications of WebSocket to
implement it in cpp-netlib.

It should be trivial to write a handler that supports the
HTTP->WebSocket upgrade, but that -- like the chunked transfer
encoding -- will have to be a separate component that would (no doubt)
be documented properly, once it's there. :)

> 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.
>

Actually, I'm more than comfortable to create a separate library
(included in cpp-netlib) that does a web template system using
Boost.Spirit's Qi+Karma, to support Django templates. The idea is it
should be possible to create a function object from a template file,
pass it a map of variants as input, which then either yields a string,
or does the rendering to the socket given a reference to a connection.

This will be dynamic though, meaning it's going to be somewhat of an
HTML/Text template compiler that creates a function object at runtime.
The function object might be able to do more things than just that,
but it should nonetheless be enough. :)

That said, you're right -- it might not be part of the core of
cpp-netlib, but having a library for rendering in a web/ directory
would be nice.

> 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.

Cool, would definitely love feedback as the library progresses. :)

Thanks for the questions, I hope these answers help.

-- 
Dean Michael Berris
deanberris.com