On Tue, May 25, 2010 at 4:52 AM, Daniel James <dnljms@gmail.com> wrote:

On 24 May 2010 15:41, Rene Rivera <grafikrobot@gmail.com> wrote:

...

There are a few things that might be difficult to achieve when implementing the website in a CMS.

That shouldn't be a problem, a lot of the existing site should be able to live alongside a CMS. I'll continue to maintain that if necessary and we could move the appropriate pages to the CMS or the wiki over time.

Sounds like a good plan. :) So who has the keys to the kingdom (so to speak) and have access to the server hosting the current site? I can get some help with a few designer friends who might be interested in contributing to theming the boost.org site. I'll go ahead and try copy-editing some of the web content already out there and see if I can deal with the current tool-chain. Thanks Daniel! -- Dean Michael Berris deanberris.com

On 25 May 2010 03:49, OvermindDL1 <overminddl1@gmail.com> wrote:

Could always create such a site using Wt[0] or so in pure C++/Boost itself for a good demonstration, would be simple enough to do, just have to remake a few things that already exist out there in other languages, not hard though.

[0] http://www.webtoolkit.eu/wt

Isn't Wt more orientated towards developing applications rather than hosting content? Daniel

...

...

Could always create such a site using Wt[0] or so in pure C++/Boost

[0] http://www.webtoolkit.eu/wt

Isn't Wt more orientated towards developing applications rather than hosting content?

Not necessarily, even the main Wt site is very static.  The main bits I like about it are: - It is like developing a gui application, using signal handlers, etc...

Few words about Wt model: - It holds server side live object for every user session which is quite huge overhead for high traffic web site. There is a quote from their docs:

Thus, for every new session, Wt spawns a new process. This has the main benefit of enjoying kernel-level memory protection between user sessions.

I don't think that it is true for latest versions but it is quite bad design for scalability. - Wt designed as GUI over HTTP/HTML replacement of Desktop application. It may be nice idea for embedded GUI systems or for highly interactive applications as let's say like Goodle Docs but it not good for content driven sites where content comes first and GUI widgets second. - Web development is far from begin close to GUI development. It has it's own ways to do stuff and trying simulate one with other doesn't do any good to both web and GUI development.

It is pure C++, what is probably all of ours favorite language,

To be honest. I love C++, I'm the author of CppCMS and I would be really pleased if Boost web site was using CppCMS for C++ web development. But I don't see advantage of C++ development for web unless: - You have **very** high traffic web sites - You have very low resources (embedded systems). See: http://art-blog.no-ip.info/wikipp/en/page/rationale http://art-blog.no-ip.info/wikipp/en/page/when_to_use_cppcms

That cppcms might work as well, but it is a lot more low-level the whole way through.

The CppCMS is not "lower-level" C++ web framework. It is just traditional MVC web framework unlike Wt which is mix of GUI and Web. CppCMS does almost anything that any other web framework does but it uses model familiar for any web developer - MVC. Bottom line: ------------ 1. I would not recommend using C++ for Boost web site unless you want to do this as proof of concept. Frameworks like Django, RoR or even existing CMS like Drupal would be much easier and faster to implement. Giving good caching tools for this frameworks you'll also get quite good performance (finally Boost.org is not Wikipedia web site) 2. If you do think that having Boost's site written in C++ gives added value that I would recommend you using CppCMS as it is much more content oriented. Example, CppCMS wiki: http://art-blog.no-ip.info/wikipp/en/page/main Note if it responds slowly it is due to my crappy internet provider. not due to framework itself. Just my $0.02 Artyom

otherwise you are free to kill the session once served.  The amount of data it holds is only your own design, can be as little or large as necessary.

There are two points: 1. Without caching (and AFAIK Wt does not even has such concept) you'll get stuck very fast. Even C++ is faster then PHP by order of magnitude this will not save you with large DB when queries are not so cheep. 2. Web is stateless for 99% percent of visitors. Giving a session to each request IMHO is bad idea.

True, but it can handle a very Qt style or design (which I personally do not like, nor do I use it), or a very CSS centric style, or any mix.

As I told you, IMHO web is not GUI... Thinking of it as GUI just makes things bad.

Oh not even, the main advantage of web design in C++ is its powerful capabilities and ability to abstract things away. 

This is not about C++, it is about framework.

Since I started using Wt I can get a site running faster then I ever could have with PHP or Python

I'm not talking about plain PHP, or plain Python. I'm talking about using web framework like Django.

What I meant by low level is that it has no higher level abstractions as Wt has, it is nothing but pure MVC, where Wt is more like Qt (which is MVS anyway, but like a GUI program, or you can use the lower-level capabilities if you so wished).  CppCMS does *not* do near what Wt has, I tried it (I do prefer its license over Wt's),

The point that Wt tries to make web development as GUI. I think that web developer should write HTML, should write JavaScript (actually using one of JavaScript toolkits like JQuery) and write server side code. Hiding this behind the "GUI" framework leads to bad design. HTTP connections are not cheap, the signals/slots design make designer to forget when comes behind the scenes. Signals and slots are good when they called withing same process and not over RPC that is passed over HTTP. This abstraction leads to bad code, bad design and total misunderstanding what web is.

Good caching is useful, no matter what you use.

AFAIK Wt does not even has such concept... While it is one of the central design concepts of CppCMS - efficient caching.

 One major difference is that you do not need to write templates as in CppCMS (well, you could also write out raw html from CppCMS), since Wt lets you design it like a Gui app, you can create things *FAR* quicker

I disagree with you that writing HTML slows things down. It makes them clearer, easier to debug and smaller.

So on and so forth.  I tried using CppCMS, but it just does not do anywhere near as much to smooth the workflow in comparison.

- When had you tried it? - Which version? - What had you written with it? And: - How much time would it take to write an application like Wikipp in Wt? - What performance will you get? It took me about several evenings only to write such application from the begging to the end including testing, and deploying and fixing CppCMS bugs I had found. And it was first serious CppCMS application. It holds about 2,500 requests per second on 1CPU machine.

Ditto, and a couple years of experience with Wt, and a decade with PHP, and a **few months** with CppCMS.

Good point. Summary: -------- - Developing web application as you develop GUI is not suited for general web development - Signals/Slots mode has big overhead and hides too much from developer. - HTML and templates are essential for web development, hiding them behind Qt like "layout" abstracts brings back and not forward. Best, Artyom

On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

otherwise you are free to kill the session once served.  The amount of data it holds is only your own design, can be as little or large as necessary.

There are two points:

1. Without caching (and AFAIK Wt does not even has such concept)   you'll get stuck very fast. Even C++ is faster then PHP by   order of magnitude this will not save you with large DB when   queries are not so cheep.

Wt is designed to be outright cached by an external caching program, but it is trivial (and I have done so) to embed caching yourself (and by trivial, I mean it took less then 5 minutes to code up). 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. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

2. Web is stateless for 99% percent of visitors. Giving a session   to each request IMHO is bad idea.

Exactly, there is no point, designing most of it to be stateless would be fine, although even holding state would not matter much, even assuming some *massive* per-user session sizes of 200kb each still lets it handle far more people then the Boost site would ever get at any single instant. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

True, but it can handle a very Qt style or design (which I personally do not like, nor do I use it), or a very CSS centric style, or any mix.

As I told you, IMHO web is not GUI... Thinking of it as GUI just makes things bad.

I beg to differ, what is HTML if not a way of rendering an interface, and CSS to design a theme, and javascript to make it interactive? Web in general is not a GUI, just as the computer in general is not a GUI, it is just the primary (not the only) way of interacting with the system. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

Oh not even, the main advantage of web design in C++ is its powerful capabilities and ability to abstract things away.

This is not about C++, it is about framework.

Exactly, and Wt can do just about anything you need, plus if you are so against C++, use Wt in Java, it is exposed to other languages, not just C++, C++ just happens to be what it is made in. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

Since I started using Wt I can get a site running faster then I ever could have with PHP or Python

I'm not talking about plain PHP, or plain Python. I'm talking about using web framework like Django.

As mentioned below, DJango and others are fine, but if you ever really have used them, you find that you run into limitations very quickly, in addition to creating something in Wt is faster due to the need to create templates in those others. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

What I meant by low level is that it has no higher level abstractions as Wt has, it is nothing but pure MVC, where Wt is more like Qt (which is MVS anyway, but like a GUI program, or you can use the lower-level capabilities if you so wished).  CppCMS does *not* do near what Wt has, I tried it (I do prefer its license over Wt's),

The point that Wt tries to make web development as GUI.

Only for the parts of it that actually are, if you need to make RSS feeds, serve some static random content, generate dynamic images, or anything else you can imagine, it is made for that as well. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

I think that web developer should write HTML, should write JavaScript (actually using one of JavaScript toolkits like JQuery) and write server side code.

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...? I certainly would not, I want to get things done fast and have it work everywhere. If I wrote the HTML myself then I would have to deal with all the little bugs from all the different browsers, when Wt handles that all for me. Besides, I do not have to use its QT-like interface, it is trivial to send HTML too, but then you lose advantages like only changing the parts of the page that need updating instead of refreshing everything. Oh, and yes, Wt does use jQuery internally, and it makes it trivial to connect Javascript and C++ together if you have any custom code that needs to be run client-side (as I had a lot of in one of my projects). On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

Hiding this behind the "GUI" framework leads to bad design.

So wxWidgets, Forms, Qt, GTK, etc... all encourage bad design? I just do not see that, where is the proof? On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

HTTP connections are not cheap, the signals/slots design make designer to forget when comes behind the scenes.

Exactly, they are not cheap, Wt minimizes the need of them. If you just send a static page, it compresses it in any necessary way. If you send dynamic pages, and the user does a lot of updating in the page that requires lots of little things updated, then Wt combines all the request into one large response and sends in en bulk (compressed of course). Using the signals/slots design lets it combine requests and reduce them very well, far better then any plain HTML setup. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

Signals and slots are good when they called withing same process and not over RPC that is passed over HTTP.

Pure signals/slots in Wt are server-side only, designed to be called within the same process, even by different users interacting with each other (see the chat example at http://www.webtoolkit.eu/wt/examples/simplechat/simplechat.wt ), there are two types of external 'callbacks', both which are transparently converted to use server-side signals, and two types of external sent 'signals'. The two callbacks are when a user clicks a url link or a form submit, Wt handles converting that to proper callbacks on the server-side if necessary, and the other is a javascript link, which is the basic type of Javascript callback, such as when you need to do something that cannot be done in javascript (easily) and you want to do it server-side instead, you just create a Javascript slot (jslot) and register a C++ callback method (or more) with it and in your output Javascript code on the webpage you just do this: ...some javascript code and so forth; " << myjslot << "(any arguments); ... some more javascript code; and when that javascript function is called in that position then it causes an RPC callback into the server (combined with any other pending requests of course) to do what it wants, which may or may not cause a client-side change if necessary. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

This abstraction leads to bad code, bad design and total misunderstanding what web is.

I do not see how, where is the proof? Just as the old antiquated windowing systems that are still usable on modern computers exist, no one really uses them, there are always abstractions on top that allow for things like vastly enhanced code readability, easy to add in features, easy updating without changing massive amounts of code-base, etc... On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

Good caching is useful, no matter what you use.

AFAIK Wt does not even has such concept... While it is one of the central design concepts of CppCMS - efficient caching.

It does not have one built-in, it is designed to be used with external caching systems, but it is still extremely easy to create your own inside of it, 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. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

 One major difference is that you do not need to write templates as in CppCMS (well, you could also write out raw html from CppCMS), since Wt lets you design it like a Gui app, you can create things *FAR* quicker

I disagree with you that writing HTML slows things down. It makes them clearer, easier to debug and smaller.

And I completely disagree with that. Writing HTML compared to writing *nothing* could in no way be faster. It does not make things clearer, it only adds in more noise with all the other css and javascript crap in the way, and it in fact makes it vastly *harder* to debug due to the way different browsers are broken in different ways, better to not write it and let something else that already knows how to handle all the broken stuff automatically. And again, writing HTML compared to writing *nothing*, noticeable size different there for sure. Also, do note, Wt has a template engine called WTemplate, although you could use any other, or do not use it at all, I have never used it, it does support displaying arbitrary widgets of any complexity too, so you still have the full power of Wt with whatever you like about templates. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

So on and so forth.  I tried using CppCMS, but it just does not do anywhere near as much to smooth the workflow in comparison.

- When had you tried it? - Which version? - What had you written with it?

And:

- How much time would it take to write an application like Wikipp in Wt? - What performance will you get?

I tried it when you introduced it to boost when talking about Boost.Locale a few months back, unsure what the version was. I just followed the tutorials then tried to write something interactive as a test (a copy of something I made in Wt a while back). How much time to write an application like Wikipp in Wt, hmm, very short no doubt, 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. First of all, I notice a templates and mo/p4 directories, I do admit that I have become a bit allergic to templates as of late due to the ease of use of not needing them now (although you can still do them in Wt no doubt), but I do notice that whatever template language that is, it is quite hard to read, all this template code and HTML mixed together, it seems you have to manually handle sidebars and so forth, easy potential for things to break, and the generated cpp from it is even harder to read, while no doubt requiring a pre-processing step. As for the mo/p4 directories, obviously for internationalization. Wt's, I admit, is not as advanced as Boost.Locale (although they will probably use Boost.Locale should it end up in Boost anyway), but theirs is made up of simple xml files, different directories for different languages, different files for different sections of the app, not just for localization, but can also be used for theming in a different way letting you use arbitrary html and so forth (if you let it). It would be simple to use Boost.Locale within Wt as-is though, it does not absolutely mandate styles. 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)); 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). 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); } """ This same function in Wt might be this (using its own DB system, which is still rather new, but you could use any other if you wanted): """ void page::display(string slug) { this->slug=slug; dbo::Transaction t(*session_); dbo::ptr<Page> page = session.find<Page>().where("lang = ? AND slug=?") .bind(locale).bind(slug); if(!page) { string redirect=edit_url(); app->redirect(redirect); return; } title->setText(page.title); // This is set to show html as text content->setText(page.content); // This is set to pass through html, after making sure it is clean. } """ The rest of the functions also look like they would go quite fast to convert. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

It took me about several evenings only to write such application from the begging to the end including testing, and deploying and fixing CppCMS bugs I had found.

And it was first serious CppCMS application.

Making such a Wiki would probably take even less time, and add an RSS feed for latest updates in one more function, and etc... On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

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. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

...

Ditto, and a couple years of experience with Wt, and a decade with PHP, and a **few months** with CppCMS.

Good point.

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. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

Summary: --------

- Developing web application as you develop GUI is not suited for  general web development

Oh it very much is well suited for that, well, if you are making an interface, for RSS feeds, image generation, *whatever*, Wt has things for that too. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

- Signals/Slots mode has big overhead and hides too much from developer.

I do not see how it hides anything, it seems to make connections between things very explicit and clear, while being executing quite fast and being very simple to use. On Wed, Jun 2, 2010 at 1:10 AM, Artyom <artyomtnk@yahoo.com> wrote:

- HTML and templates are essential for web development, hiding them  behind Qt like "layout" abstracts brings back and not forward.

HTML and templates are like working with the base C API for a windowing system compared to all of the graphical toolkits built on top. Using that low level API gains you *nothing*, since everything higher can do everything anyway, but the higher levels also help you to design vastly easier to reuse components and helping to vastly reduce the amount of bugs while reducing programming and testing time. On Wed, Jun 2, 2010 at 8:14 AM, David Abrahams <dave@boostpro.com> wrote:

At Wed, 2 Jun 2010 00:10:39 -0600, OvermindDL1 wrote:

...

I certainly know that is not true when hosting on Windows, on *nix I believe it uses FastCGI.  The user session data is only important for when the user *has* a session (logged in or so?), otherwise you are free to kill the session once served.  The amount of data it holds is only your own design, can be as little or large as necessary.

Wow, this Wt thing looks really, really cool.  I don't suppose they want to be part of Boost?

I would doubt it, it is a sub-project of the Emweb company with dual GPL/Commercial license, they only keep it running and updating to support their own efforts, like the Qt/Nokia relationship. Personally I question some of their design decisions, it would be quite interesting to create a replacement that is better optimized (in the boost style) with all that power. I can propose the question though. On Wed, Jun 2, 2010 at 8:20 AM, David Abrahams <dave@boostpro.com> wrote:

At Wed, 2 Jun 2010 00:10:48 -0700 (PDT), Artyom wrote:

...

...

Ditto, and a couple years of experience with Wt, and a decade with PHP, and a **few months** with CppCMS.

Good point.

Summary: --------

- Developing web application as you develop GUI is not suited for   general web development

You haven't given any evidence to support this claim AFAICT, but I may have missed it.

Ditto, I have been wondering about that statement too, I have seen no claims for it, and many against it. On Wed, Jun 2, 2010 at 8:20 AM, David Abrahams <dave@boostpro.com> wrote:

...

- Signals/Slots mode has big overhead and hides too much from developer.

I can understand that argument.  Not sure I agree that it hides too much, but at least I understand it.

I am not really sure how it hides anything, I have lots of things scattered about my code like this: userLoggedIn->emit(user); clicked().connect(bind(&newPost, this)); string createImageCall(createImageCallback()+"(type, h, w, text, 'png')"); { JSlot *callOnClient = new JSlot(javascript, this); callOnClient.exec("null", "null"); // On the next request to the client, this will be sent along with all of the other data and executed } etc... This all *vastly* simplifies the code and makes things very explicit On Wed, Jun 2, 2010 at 8:20 AM, David Abrahams <dave@boostpro.com> wrote:

...

- HTML and templates are essential for web development, hiding them   behind Qt like "layout" abstracts brings back and not forward.

This seems to be an entirely subjective statement.  I'd like to understand whether it's the same as saying “machine instructions are essential for coding; hiding them behind Pascal-like ‘high-level language’ abstractions brings us back and not forward,” which I would reject on its face, or if there's something more to it.

Note that I don't reject all such arguments.  For example, I believe that today's typesafe languages force us too far away from the machine model to achieve the highest efficiency.  But then, that's phrased as a tradeoff between safety and efficiency; your statement isn't.

That is exactly why I like the Wt model, it lets you do things in the high level, in templates, in raw HTML, or anything else you can come up with, while letting you mix-and-match it all as you wish.

…since this is now about C++ web frameworks and not so much about maintaining boost.org. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

At Wed, 2 Jun 2010 13:00:21 -0600, OvermindDL1 wrote:

...

Wow, this Wt thing looks really, really cool.  I don't suppose they want to be part of Boost?

I would doubt it, it is a sub-project of the Emweb company with dual GPL/Commercial license, they only keep it running and updating to support their own efforts, like the Qt/Nokia relationship. Personally I question some of their design decisions, it would be quite interesting to create a replacement that is better optimized (in the boost style) with all that power. I can propose the question though.

If they are unlikely to be interested, maybe it would be better to quietly go about building the Boost Wt (which I presume would generate lots of other infrastructure Boost “should” have as a side-effect). Who's volunteering? :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com

At Wed, 2 Jun 2010 00:10:39 -0600, OvermindDL1 wrote:

...

Few words about Wt model:

- It holds server side live object for every user session which is quite  huge overhead for high traffic web site.

 There is a quote from their docs:

 > Thus, for every new session, Wt spawns a new process.  > This has the main benefit of enjoying kernel-level memory protection  > between user sessions.

 I don't think that it is true for latest versions but it is quite  bad design for scalability.

I certainly know that is not true when hosting on Windows, on *nix I believe it uses FastCGI. The user session data is only important for when the user *has* a session (logged in or so?), otherwise you are free to kill the session once served. The amount of data it holds is only your own design, can be as little or large as necessary.

Wow, this Wt thing looks really, really cool. I don't suppose they want to be part of Boost? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

At Tue, 25 May 2010 16:02:28 +0100, Mateusz Loskot wrote:

There is also Artyom's CppCMS

http://cppcms.sourceforge.net/wikipp/en/page/main

This project consists of or breeds potentially very interesting parts like Boost.Locale, etc.

That is exactly the kind of fringe technology I would like to avoid. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

On Mon, May 24, 2010 at 10:41 PM, Rene Rivera <grafikrobot@gmail.com> wrote:

On 5/24/2010 12:09 AM, Dean Michael Berris wrote:

...

If you were at the BoostCon 2010 panel session, I suggested that maintaining boost.org can be a less painful process and that I was willing to help out in transitioning the current site from the way it is currently set up to maybe use Wordpress to host the site. There are other options that I would like to explore only after looking at many different tools and the current process of maintaining it.

There are a few things that might be difficult to achieve when implementing the website in a CMS.

I have thought about some of these, including the per-library generated documentation and there are a few things which we can do to make that a little less painful. The amount of things that can be done better with a CMS include: * Posting of news articles and updates to the developer community. * Holding discussions on specific topics or specific subjects. * Gathering feedback from the community at large of developers and users about certain things in context (email works for things like these discussions and only if people invest in learning the netiquette required to make discussions on mailing lists manageable). * Updating content that is already available. Wiki's work for collaborative editing but ultimately the site should cater not only for the developers writing the documentation but be geared more towards those that are reading it. I have a few more things to say about this and I'll most probably write them out in another email for more concrete action.

...

I tried sending mail to the Boost-docs list but I haven't gotten any responses yet so I chose to send another email to the developers mailing list.

Hm, I don't an email on the docs list :-\ I'll cross post to the docs list just in case it ever show up.

Yeah, I tried 3 times and I wasn't able to get any luck getting the email to go through. I think this is better held on the developer mailing list anyway to get feedback also from those who want to chime in. :)

...

There are a couple of questions I would like to ask and would really appreciated getting an answer about:

1. Is there currently a boost.org web team? If so, who are in the team?

Right now it would be Daniel James, Beman Dawes (for the release docs), regular library authors, and myself. Although Daniel has essential done all of it.. Since there really isn't that much to do. I think he's spent idle time rewriting some pf the PHP scripts from the rather nasty code I originally wrote ;-)

Ah, alright, thanks for the pointers. Now I know who to ask about migrating the stuff from the current situation to a Wordpress or <insert CMS that works here>. :)

...

2. What is the current process of building the boost.org site? What is the toolchain used and how are changes managed?

When I designed it I wanted to use existing "tools" that developers already knew how to use. Hence most of the web site is plain HTML. Parts are PHP HTML with supporting PHP class code, for example the libraries list and online documentation. The feeds, i.e. downloads and news, are Quickbook docs that get translated to Docbook and then filtered with a Python script to generate static RSS. They are displayed in the site by PHP from reading the RSS and doing minor translation to HTML. The big chunk of PHP code deals with the documentation. When looking at the documentation pages a PHP script looks up pages directly on the Boost release ZIP archive of a given version, uncompresses the file, optionally post-processes it into HTML to fit the style (mostly just replaces the header&footer), and spits out the docs. Hopefully you've already found the web-site dev instructions <http://www.boost.org/development/website_updating.html>.

Wow. That's quite a toolchain, thanks for explaining it. I really had no idea how much work was needed to get the website up to the state it currently is in. So we still touch raw HTML? That's a little painful. Even the web designers/developers I know are moving to haml [0] which is a lot friendlier for people writing code which eventually gets turned into HTML by some processor. There are also other tools like Jekyll [1] and Sphinx [2] which deal with Markdown and Restructured Text respectively to generate nice static web sites. [0] http://haml-lang.com/ [1] http://github.com/mojombo/jekyll [2] http://sphinx.pocoo.org/ Thanks for the link too, I haven't seen this yet. I'll give it a whirl and see how far I can get to making a contribution to low-hanging fruit.

...

Pending a "full" proposal I would definitely appreciate thoughts about the matter too.

One idea I had, before Boostcon when the whole where should Boost go discussion came up, was to move to using something like the Drupal model for sub-projects <http://drupal.org/project/Modules>. Particularly how the projects each have their own web area. And also how the groups section area of Drupal works <http://groups.drupal.org/>.

Note, I'm not suggesting Drupal (even if I do currently use it). Just some of the structure they employ for projects since it does mirror the conglomerate project structure Boost has.

I agree, and it would be nice if we would use something like Wordpress MU so that we can have library maintainers manage their own sub-sites. I can totally imagine something like a mpl.boost.org blog/documentation site where the users can post comments on articles and what's going on with the library, and potentially download prepackaged distributable releases of the library (containing all other dependencies it may have). I'm still toying around with whether a web-based forum ala StackOverflow would work on a per-library basis as well, which can be a totally independent feature should library maintainers want them for their own sites or not. Without going into the "let's decouple the boost libraries" discussion (which should be interesting in itself) it would be good for Boost libraries to have a place in the web where users can get immediate support for frequently asked questions, be able to file bugs "easily", and then be able to engage the communities that follow each boost library to thrive. The maintainers can then write out rationales, examples, and other things on the web that they (and users) can point to for a "canonical" answer that usually gets lost in the mailing list archives and is buried in sometimes unmanageable contextual information. Another thing that would be nice to have would be having mailing lists for each Boost-accepted library. This allows the Boost developer mailing list to be a general discussion area about Boost as a whole and the development process and questions about cross-library interactions. Much like how Spirit has its own mailing list and active user/developer community around it -- which I think should be the model for all the other Boost libraries that are actively being used and maintained. I'm sure there's going to be another discussion about subversion and git, whether to release individual libraries or a monolithic distribution, etc. but I'd like to start with the website to make it more inviting to the community to use and interact through it. Thanks again and I'll write up that concrete proposal soon enough. :) -- Dean Michael Berris deanberris.com

On Tue, May 25, 2010 at 11:43 AM, David Abrahams <dave@boostpro.com> wrote:

At Tue, 25 May 2010 10:27:18 +0800, Dean Michael Berris wrote:

...

Wiki's work for collaborative editing but ultimately the site should cater not only for the developers writing the documentation but be geared more towards those that are reading it.

I have a few more things to say about this and I'll most probably write them out in another email for more concrete action.

One thing I've noticed about blogs is that they seem to encourage participation in comments by people who might be not want to post in a forum (like this one) where everything has equal status.

Yup, I think it's because the barrier to entry with participation in blogs is technically lower than with mailing lists. With blogs, you can (typically) comment right away providing as little required information as possible. I think the users list might be a good source of information from which typical responses can be culled and distilled into forms that are more "comment-friendly" in blog posts. Not only is this good Google juice but it's also just more convenient to manage discussions on a specific topic with enough context without having to ask people to not top-post or overquote. ;) -- Dean Michael Berris deanberris.com

On Tue, May 25, 2010 at 6:05 PM, Daniel James <dnljms@gmail.com> wrote:

On 25 May 2010 03:27, Dean Michael Berris <mikhailberis@gmail.com> wrote:

...

So we still touch raw HTML? That's a little painful.

Not really, HTML has excellent tool support. Several developers want to use WYSIWYG editors.

Well if absolutely necessary, then touching HTML shouldn't be hard. It just somehow in my view is not a good use of time dealing with actual raw HTML than a lighter representation like RST/Quickbook/HAML. Although that's just me. If WYSIWYG editors is what's needed, then I've seen one of the best browser-based WYSIWYG editors already shipping in Wordpress so that should be a welcome feature.

...

Even the web designers/developers I know are moving to haml [0] which is a lot friendlier for people writing code which eventually gets turned into HTML by some processor.

We can't really expect people to learn another technology and install another toolset. I think you need to understand HTML in order to use haml anyway.

Yup, that was a bad example -- and is mostly geared towards people doing websites from scratch. The point I was trying to make is if we can stay as far away from HTML as possible, then that should be better than touching raw HTML, IMO. ;)

...

There are also other tools like Jekyll [1] and Sphinx [2] which deal with Markdown and Restructured Text respectively to generate nice static web sites.

The website predates both tools. Hyde would be a better choice than Jekyll since Python is preferred round here. I'd be a little worried about how flexible they are.

Yup, but if Python was preferred I'd think Sphinx would be a better solution for documentation.

...

I agree, and it would be nice if we would use something like Wordpress MU so that we can have library maintainers manage their own sub-sites.

I'm trying not to be the voice of pessimism, but I don't think that's feasible. Library maintainers already have enough of a workload, and several libraries don't even have maintainers.

Sure, for libraries that aren't maintained or don't need a separate sub-site, then the main boost site (or a page in the boost.org site) would be sufficient in the meantime. I would say if someone else wanted to step in an handle for example the sub-site for a particular library (like Boost.Pool) then having a Wordpress MU installation would make is significantly trivial to let that someone take over that part of the site. Remember, one of the goals is to encourage participation -- lowering the barrier to entry in terms of contributing to "community building" would be, I believe, important to getting more people involved at least in the web aspect. For other libraries that already have a following, letting the maintainer do things easily just with a browser should be a lot better experience compared to the way things are going now. Coming with with FAQ's, examples, and other specific pages just for a particular library should be as easy as possible. Getting comments and feedback from the users through the website should be the same as well.

...

I'm still toying around with whether a web-based forum ala StackOverflow would work on a per-library basis as well, which can be a totally independent feature should library maintainers want them for their own sites or not.

Why not just use StackOverflow? Since they've recently announced an API, it might be possible to integrate it into the site in some manner.

That's one possibility and it's still one of those things that begs the question -- how hard/easy would that be? Unless there's already a WP plugin for that yet, I don't see why we have to go through extra effort to use StackOverflow from day 1. I'm positive there would be one if there's not one already and it would definitely just be a matter of installing and configuring that plugin when the day comes. HTH -- Dean Michael Berris deanberris.com

On Tue, May 25, 2010 at 9:54 PM, Joel Falcou <joel.falcou@lri.fr> wrote:

Dean Michael Berris wrote:

...

Yup, but if Python was preferred I'd think Sphinx would be a better solution for documentation.

I'm all up for using Sphinx as a doc generator for boost. I think Troy Strashzeim has a spiffy boost-like template written in Sphinx.

Oh cool! That would be really neat. Now I think for all intents and purposes I have to think about whether there is a way for Sphinx to understand Quickbook or use it underneath. I know it should be feasible to do but it's also some work that I would much rather avoid or not have to do. :D -- Dean Michael Berris deanberris.com

At Tue, 25 May 2010 21:57:42 +0800, Dean Michael Berris wrote:

On Tue, May 25, 2010 at 9:54 PM, Joel Falcou <joel.falcou@lri.fr> wrote:

...

Dean Michael Berris wrote:

...

Yup, but if Python was preferred I'd think Sphinx would be a better solution for documentation.

I'm all up for using Sphinx as a doc generator for boost. I think Troy Strashzeim has a spiffy boost-like template written in Sphinx.

Oh cool! That would be really neat.

Now I think for all intents and purposes I have to think about whether there is a way for Sphinx to understand Quickbook or use it underneath. I know it should be feasible to do but it's also some work that I would much rather avoid or not have to do. :D

Sphinx == docutils underneath. It has front-end readers, a transform phase, and backend writers. To get it to understand Quickbook one would write a Quickbook Reader component. http://www.python.org/dev/peps/pep-0258/#docutils-project-model I suggest trying to avoid tackling this until later. It doesn't seem like there's an essential need to change the way we deal with quickbook. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

AMDG joel falcou wrote:

David Abrahams wrote:

...

Sphinx == docutils underneath. It has front-end readers, a transform phase, and backend writers. To get it to understand Quickbook one would write a Quickbook Reader component. http://www.python.org/dev/peps/pep-0258/#docutils-project-model

I suggest trying to avoid tackling this until later. It doesn't seem like there's an essential need to change the way we deal with quickbook Well, havign it as an option *could* be nice. I have no pb setting sphinx up and making it do thing. I'm still fighting with boost book for w/e reason.

What problems are you having with BoostBook? In Christ, Steven Watanabe

AMDG joel falcou wrote:

Steven Watanabe wrote:

...

What problems are you having with BoostBook? Well, last time I tried follwoing the Getting Started Guide, everythign went fine until I tried to build an existing lib doc. It fails by complaining about no XLST being defined. I have to digg further tough but back then we had some deadlien and we just switched.

Okay. If you can provide details, I can try to either make things "just work" or improve the error messages. In Christ, Steven Watanabe

On 05/25/2010 09:54 AM, Joel Falcou wrote:

Dean Michael Berris wrote:

...

Yup, but if Python was preferred I'd think Sphinx would be a better solution for documentation.

I'm all up for using Sphinx as a doc generator for boost. I think Troy Strashzeim has a spiffy boost-like template written in Sphinx.

With CLang now supporting Boost, I have plans to hook Synopsis up with it (http://synopsis.fresco.org), to improve its API documentation capabilities. Synopsis supports ReST - formatted inline docs, and thus would blend nicely with Sphinx. (And I agree, Sphinx is a great tool. I have been using it in a number of places to generate entire websites.) FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...

At Tue, 25 May 2010 11:05:10 +0100, Daniel James wrote:

On 25 May 2010 03:27, Dean Michael Berris <mikhailberis@gmail.com> wrote:

...

So we still touch raw HTML? That's a little painful.

Not really, HTML has excellent tool support. Several developers want to use WYSIWYG editors.

...

Even the web designers/developers I know are moving to haml [0] which is a lot friendlier for people writing code which eventually gets turned into HTML by some processor.

We can't really expect people to learn another technology and install another toolset. I think you need to understand HTML in order to use haml anyway.

...

There are also other tools like Jekyll [1] and Sphinx [2] which deal with Markdown and Restructured Text respectively to generate nice static web sites.

The website predates both tools. Hyde would be a better choice than Jekyll since Python is preferred round here. I'd be a little worried about how flexible they are.

Underlying technology is of the least importance. I use Wordpress (which is PHP) not because I am a fan of PHP but because it “just works,” is accessible to all categories of users, and many people use it already. It's much more important to pick a tool that has enormous momentum and support from outside our little community than it is to use technology we “prefer.” That's also why I'd like not to waste any time trying to figure out how to do these things with C++ or especially with Boost.

...

I agree, and it would be nice if we would use something like Wordpress MU so that we can have library maintainers manage their own sub-sites.

I'm trying not to be the voice of pessimism, but I don't think that's feasible. Library maintainers already have enough of a workload, and several libraries don't even have maintainers.

I disagree. Part of the reason the workload is so high is that maintaining documentation and other information about libraries is too labor-intensive. Make it more accessible and the work gets easier. -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com

At Tue, 25 May 2010 15:56:39 +0100,Daniel James wrote:

...

I use Wordpress (which is PHP) not because I am a fan of PHP but because it “just works,” is accessible to all categories of users, and many people use it already.  It's much more important to pick a tool that has enormous momentum and support from outside our little community than it is to use technology we “prefer.”  That's also why I'd like not to waste any time trying to figure out how to do these things with C++ or especially with Boost.

Are you responding to me there?

I'm responding to earlier posts that floated e.g., the idea of building something on Boost.Spirit -- Dave Abrahams Meet me at BoostCon: http://www.boostcon.com BoostPro Computing http://www.boostpro.com