Re: [boost] [Boost-docs] Maintaining boost.org

Subject: Re: [boost] [Boost-docs] Maintaining boost.org
From: Artyom (artyomtnk_at_[hidden])
Date: 2010-06-02 16:03:23

> 
> Quite true with the DB queries, but I am not using C++ here
> for its
> speed, I am using it because it is powerful, I know it, and
> it can
> potentially do anything that I could ever imagine needing
> to do
> anywhere, to get around big DB queries is a design issue,
> not a
> language issue.
> 


I'd suggest you to read this article about web performance and C++:

http://art-blog.no-ip.info/cppcms/blog/post/42

 
> Why should they write HTML?  Would you prefer to use
> the Win32 C API
> for creating graphical programs instead of 
> wxWidgets, MFC,
> Forms, Qt,
> etc...? 

HTML is the core, you may try to hide it but it is always there,
Also graphics designers are much more familiar with it then with
Signals/Slots.

Additional important point: Why you should not use tools like
Front-Page for web development? Because it's simplicity makes
things harder when something goes out of the standard scope.

So no... The fact that the web looks like it looks today we need
to thank all "automatic" tools that were developed for web and filled
it with (sorry) crap.

About GUI toolkits
------------------

You probably come from Windows background. Qt and GTK are Native tools
for Unix world which build over kind of **very** low level primitives.
For example there is no such thing like button or text-box in X-Server API
above which they are build.

So it is actually **the** native GUI. Under windows they wrap Win32
API.

BTW you also forget that they provide abstraction from OS level API
because you have no Win32 API on Unix and you have no X-Server on Windows.

But HTML is actually can be written properly for any modern browser
probably with very few adjustments for some outdated browsers.

Also as time passes, browsers become more standard. So...

> Exactly, they are not cheap, Wt minimizes the need of
> them.  

It is same like in Asp.Net you connect server-side events to button
click and forget how painful it may be.

> http://www.webtoolkit.eu/wt/examples/simplechat/simplechat.wt
> ), there
> are two types of external 'callbacks', both which are
> transparently

Take a look on this code: 

http://cppcms.svn.sourceforge.net/viewvc/cppcms/framework/branches/refactoring/src/hello_world.cpp?revision=1235&view=markup

class called "chat" 
Lines 55-114 and the HTML part:
http://cppcms.svn.sourceforge.net/viewvc/cppcms/framework/branches/refactoring/src/the_chat.html?revision=1180&view=markup

Of course it is much simpler then Wt chat example (It is just a testing
of server side events dispatching)

But is is clear how stuff works (at least for me) and it gives not 
more code then Wt ones.

It is CppCMS 1.x.x with full Comet support.

> 
> It does not have one built-in, it is designed to be used
> with external
> caching systems,

External caching systems are very weak as they have very limited
tools for cache invalidation.

> but it is still extremely easy to create
> your own
> inside of it,

Do you really think so? Cache shared between processes or network,
with complex invalidation and so on?

Ohhhh. it is far from being "simple"

Read this about how good cache system should work:

http://art-blog.no-ip.info/cppcms/blog/post/21



> if you really want Wt to come with one then I
> can submit
> mine as a patch once I clean it up a bit, nothing special.
> 

When I started working on CppCMS Wt was around. I didn't joined it
as it had very bad design concept IMHO.

So no, I'm not going to write code for wrong project. ;-)

> 
> I can do so if you wish, but let me look at
> the Wikipp
> code first, done, first I see no way of compiling, no cmake
> build
> scripts or bjam or anything that will work on the computer
> I am on
> now, so just looking at the source.

Current wikipp for CppCMS 0.0.6 uses autotools and don't support
windows, the Wikipp for beta CppCMS 1.x.x has CMake but still I don't
think it builds on Windows.


> easy potential for things to break, and the generated cpp
> from it is
> even harder to read,

I'm not expecting anyone to read generated cpp as I don't expect
most users to read assembly generated by compiler.

> 
> As for the actual code, the main application seems to be
> about as long
> as the Wt version would, although I wonder how this line
> works:
>     url.add("^/(\\w+)(/.*)$",
> boost::bind(&wiki::run,this,$1,$2));

It is binds function run to specific url. It is little bit triky
in case of wikipp as I has two steps - define locale (CppCMS supports
multiple locales in process and then dispatches actual URL.

> 
> I notice there are a lot of things that are done in CppCMS
> that take a
> lot more code to do, like a simple redirect takes two lines
> (which
> includes instancing a HTTPRedirectHeader), compared to a
> simple
> app->redirect in Wt (which can take a url or widget
> location, where
> CppCMS seems to only take a url).


This is good point and it was addressed in CppCMS 1.x.x as CgiCC was
removed from it so redirect becomes one line and has same syntax.

BTW: for your notice redirect requires two headers.

> 
> Here is the important part of the page display function:
> """
> void page::display(string slug)
> {
>     this->slug=slug;
> 
>     sql<<    "SELECT
> title,content,sidebar FROM pages WHERE lang=? AND slug=?",
>         locale,slug;
>     row r;
>     if(!sql.single(r)) {
>         string
> redirect=edit_url();
>         set_header(new
> HTTPRedirectHeader(redirect));
>         add_header("Status:
> 302 Found");
>         return;
>     }
>     ini(c);
>     r >> c.title >> c.content
> >> c.sidebar;
>     render("page",c);
> }
> """


BTW you had forgotten important lines - cache... this is one 
of most important parts ;-)

> 
> Making such a Wiki would probably take even less time, and
> add an RSS
> feed for latest updates in one more function, and etc...
> 

And what about caching? How much time would it take (including
invalidation)?

> > It holds about 2,500 requests per second on 1CPU
> machine.
> 
> I can see the Wiki being very DB constrained, so it would
> be tough to
> compare this, perhaps a dynamic non-DB page generation
> request?
> Do note, Wt's DB is very low level, using constructed
> queries and
> other such optimizations, all available for re-use without
> needing to
> regenerate.
> 

Reuse of queries will not help as HTML generation is quite
heavy process, even gzip compression can reduce the performance
by several times.

So no, queries are not the correct place to optimize.


> 
> I was searching for C++ web frameworks a while ago, CppCMS
> never came
> up, so that is why I did not notice it until your Boost
> post.
> 

I must admit it is much younger then Wt and it is under constant
development. As CppCMS 1.x.x will be released (soon)
it would bring lots of goodies that even not exist in other
web frameworks like Django and of course not in Wt.

http://art-blog.no-ip.info/wikipp/en/page/cppcms_1x_whats_new

Best,
  Artyom