We have some good news regarding the state of the POCO website. In summer, two interns will help us to do a major overhaul of the website. The following is planned:

• Some graphical/design facelifting
• Kick out tiki and replace it with MediaWiki and phpBB
• Integrate the user management of WordPress, MediaWiki and phpBB
• Implement a single-sign-on feature for WordPress, MediaWiki and phpBB

All existing tiki content (FAQ, Forums, Wiki) will be transferred to the new site. Work will start in July and we hope to complete the transition by September.

There’s a mailing list thread going on, discussing some proposals for modifications and POCO contributing process. This discussion occasionally turns heated and there is a lot of misinterpretation and misunderstanding going on, which has prompted me to summarize the contributing issues/concerns and post them in one place as a clarification for all the folks who are currently contributing or are considering to do it in the future.

Before I say anything else, let me emphasize that we always solicit contributions. We value all the contributions and give any idea due consideration within the limits of our ability. Like any other worthy endeavor, bringing a contribution to the release-grade code is hard work - there are no shortcuts to any place worth going. The hardest part is sometimes directly related to the complicated nature of the issue at hand. But more often, the hardest part is to take care of the details accompanying the process of integrating the contribution into the framework:

• Study the contribution code (and architecture, where applicable) to verify it indeed makes sense, from all the relevant standpoints, to integrate it.
• Verify the contributed code complies with the coding style guide (which reminds me that it would be nice to have automatic checker). If not, edit until it does (this can be VERY time consuming)
• Incorporate the code into POCO source files and/or directory structure.
• Modify the build system if necessary.
• Verify the code compiles on supported platforms
• Verify the tests pass on supported platforms/compilers

The above list is abstract. Amount of details and time spent on each item can vary greatly. At any rate, it is a time-consuming process. The more of the above concerns are addressed by the contributor prior to submitting the code, the less work we have to do. Ideally, the contributor addresses all of the above concerns, is a committer himself, commits the code and we have nothing to do. That’s a very rare thing to find and it is, understandably, never the case with new contributors - everyone needs some adjustment time to get the proper “feel” of the environment.

Now, a bit about the types of contributions. Here’s the list:

• Reporting POCO usage
• Opining on POCO
• Submitting Bug Reports
• Submitting Patches
• Submitting Feature Requests
• Writing a tutorial, how-to, or a technote
• Contributing classes/implementations (e.g. SMTP logging channel)
• Contributing modules (e.g. ICMP module, see ICMP*)
• Contributing libraries (e.g. MySQL connector)
• Taking ownership of a cross-cutting concern (e.g. build system for a platform/compiler, e.e.g. MinGW build)
• Submitting various ideas and concepts (see sandbox, e.g. C10K, atomic operations, etc.)
• Taking ownership of a library in trunk/sandbox (e.g. Data/Servlet)
• Modifying essential portions of the framework
• Working on alternative POCO versions/directions

OK, now, the last two items are something we do not currently have an example for, so let me spend some time explaining it. We are very willing to grant write access to someone who wants to experiment with alternative POCO directions.

Based on recent requests from some users, here are few examples:

• replacing use of mutexes with atomic operations where appropriate
• replacing threads with coroutines where apropriate
• experimenting with asynchronous IO

This is by no means a complete list. If you want to play and experiment, by all means let us know. We will give you Subversion write access and you can go play in the sandbox. Should you desire it, you can even get your own branch in the repository containing a copy of the current POCO trunk.

What is the purpose of such thing? Well, you may come up with something really cool and we may decide to backport it to mainstream POCO. There is the opposite possibility as well - you may be enamored with your work, but the POCO community may not be so thrilled, so you decide to pack your bags and launch a project of your own. Not a problem, as long as you respect the license (i.e. display it properly to give due credit to original authors), the project name is not POCO and it does not live in Poco namespace. We currently have no legal means to prevent you from doing it, but it would be rather ridiculous (and confusing) to have multiple C++ frameworks named POCO and it would only serve to hurt both parties.

Any questions?

We are currently in progress of changing the WebWidgets library. We now have a core library defining the GUI elements, the CodeGenerators aka Renderers are kept in a separate library. The renderer I am currently working on is a Codegenerator for ExtJs. The code is still very incomplete (especially callbacks, events, table stuff) but writing C++ code like that


Page::Ptr ptr = new Page("test");
TabView::Ptr ptrTab(new TabView("tab1"));
ptrTab->add(new Image("Image", Poco::URI("Sunset.jpg")));
Label::Ptr ptrLbl(new Label("Label"));
ptrLbl->setText("Hallo");
ptrTab->add(ptrLbl);

ptrFrm->add(ptrImg);
RadioButton::Ptr ptrBut2 (new RadioButton("radio"));
ptrBut2->setText("Disable");
ptrBut2->setToolTip("click here to disable");
ptrTab2->add(ptrBut2);
ptrTab->setActiveView(2);


already produces the following HTML page:

Code is not yet in SVN, I estimate another one to two weeks until you can play with it and either start
writing your own renderers or extend the extjs one.

in Dr. Dobbs

Evidence of a widespread use is important part of becoming a mainstream framework and raising a potential user confidence. From that standpoint, POCO is not quite there yet, at least not “officially”. We do get frequent hits from many commercial entities, but only a small subset is factually verified and listed to use POCO.

This is a call to POCO users for report on usage. If you are using POCO in a commercial, scientific, non-profit or any other environment worth mentioning and you are not prevented by a legal obstacle, please consider giving back to the community by letting us know about it.

Thank you,

The POCO Team

There were three significant changes to the SVN trunk and sandbox recently:

• Data keywords (use, into, et al.) were moved into Poco::Data::Keywords namespace.
• All the IO stuff (both sync and async) was moved from Foundation and Net to IO and IO::Socket
• All the Serial stuff was moved from IO to IO::Serial

All these changes do break code. We never take that lightly, but when being tidy weighs more than being 100% backward compatible we do not hesitate to do it.

The last commit was whopping 180 files. VS71 and VS90 files are not updated yet. Please bear with us and report any problems and/or errors.

Alex

Sergey Kholodilov was kind enough to share his work with us and now we have MySQL Data connector for POCO. At this time, it is only available from SVN and tested with 1.3.3 branch code on Windows, FreeBSD and Linux.

POCO community very much appreciates your contribution, Sergey.

Earlier this week, I have attended Stroustrup and Sutter on C++ session at the SD West 2008 conference in Santa Clara, CA. As usual, session was packed with information mainly focused on the upcoming standard, the multi-core revolution we are are just starting to witness and a healthy dose of humor from both speakers and audience.

So, what’s making it in the standard? Many good things, some still in the working. If I’d have to single out my favorite, it was to learn that lambdas were voted in last week, so we’ll be able to do things like this:

void f(vector& v)
{
auto p = find_if(v.begin(), v.end(), [](int x){return x<7;});
}

This is important for two reasons:

• it makes a very powerful (and underused) portion of STL - algorithms - much more convenient to use
• it is very much in sync with recent surge of interest in functional languages, so (once again) C++ remains in the mainstream

There are many things coming in, too many to mention all here. For the curious reader, WG21 page is the best source of information. Anything expected that won’t make it into the standard? Yes - garbage collection. The committee could not reach consensus on it.

Herb Sutter gave few remarkable talks and demonstrations about the brave new multi-core world we are living in. More cores means faster, right? Well, maybe. Having multiple cores can actually slow you down in some scenarios. Yes, you add cores and run slower than you did with single core. And then, less CPU cycles means shorter time, right? Well, it depends. In a multi-core universe, as it turns out, sometimes less is more. Or more is less, whichever way you want it. So, in a well-intentioned and naive attempt to optimize, you get rid of some code and you end up running - slower. If you are surprised, welcome to the club. Herb demonstrated it convincingly on a live system. Again, since I can not do it justice in this frame, details are out of scope here, but let me just mention it has to do with multi-level caches. If you follow Herb’s articles, you’ll learn about it. He’s also putting out a book on the subject later this year. No doubt it’ll make for a good bedtime reading.

Worth mentioning here is the issue of thread interruption. Quite some time ago, we’ve had a heated discussion on the topic with a Java user demanding adamantly that we put it in. I have to admit that, at the time, I was not completely familiar with the exact mechanism how Java (or C#) actually do this. However, intuitively, I knew that there can not be any magic there. It is simply a bad idea and Herb has confirmed it in one of his talks. As it turns out, Java and C# had to learn it the hard way. As for the request originator, I must be fair here and say that he recently apologized for his manners and we have gladly accepted his apology.

It was interesting to learn how concepts allow to get rid of significant chunks of iterators documentation and those clumsy traits. I was also curious and took this opportunity to ask the creator of C++ what is his position on coding activity, i.e. whether programming computers is building/construction or rather a design activity. His answer was: “When you are programming, you are designing. But more than anything else, you are learning.” I have to agree.

I have noticed that the room was packed full this time, compared to maybe ~2/3 last year. Bjarne Stroustrup confirmed that his speaking invitations are significantly on the rise in the last few years. He is also working on popularizing C++ in education and will publish a C++ textbook for novice programmers later this year.

And then, on the lighter side, Herb brought in a synthesizer, put together some geek lyrics adjusted to well known tunes, such as Bohemian Rhapsody (”Mama, just killed a thread …”) and the Cheers theme tune (”Where everybody locks the same …”). He needed support performing, so he managed to talk few clowns into singing with him in front of about 300 people. Don’t tell anyone, but your humble correspondent was one of them. Now I live in a constant state of fear hoping the thing does not somehow find its way to YouTube

The bottom line? Good conference, speakers as competent as humanly possible, a lot of useful information. In a nutshell: C++ is alive and well.

As everyone probably already knows, registration in the Wiki and Forums is broken. Today I tried to upgrade Tiki (the underlying software) to the latest revision, but that did not fix the registration issue, creating new issues instead. Now that I’m sick and tired of this big and ugly whatever named Tiki, I’d like to get rid of it as soon as possible.

I propose the following alternatives:

• get rid of the forums and replace the wiki part of Tiki with MediaWiki (or something else that seems to work well). From my experience with other projects, MediaWiki seems to work well, so I’d like to go that route. Instead of the Forums, people should use the mailing list (which works for other open source projects as well, so why not for us).
• keep both the Wiki and the Forums, and find reasonable alternatives for both (e.g., MediaWiki + phpBB). Problem: converting all the existing forum data to the new forum, which is a nontrivial task.
• have someone (definitely not me) fix our Tiki installation.

Any opinions?

Going to Embedded World next week in Nuremberg, Germany? You can see a cool demo powered by the POCO C++ Libraries as well as POCO Remoting featured at the booth of Atlantik Elektronik (hall 12, booth 444). I am looking forward to seeing you there!