I am happy to announce that release 1.3.3 of the POCO C++ Libraries is finally available. More than any other release before, this release was a true community effort. Sergey Kholodilov contributed the MySQL connector for Data, and Ferdinand Beyer contributed the foundation of what now is the Crypto library. Chris Johnson helped bringing POCO to Cygwin and MinGW. Jiang Shan provided valuable input and bugfixes. Sergey Skorokhodov backported bugfixes from the trunk to the 1.3.3 release. And many others sent us bug reports or patches (see the Contributors page for a full list). Thank you! Last but not least I’d like to thank Alex “Mr. Data” Fabijanic, who was the driving force behind that release, and who also helped to bring POCO forward during periods when I was too much occupied by other projects.

So, what’s new in 1.3.3?
Release 1.3.3 of the POCO C++ Libraries contains over 60 improvements and bug fixes. Improvements have been made to the multithreading classes (user-settable stack size), to events (simplified syntax based on new delegate function template), logging (time-based log file rotation), reactor framework, and others (see the CHANGELOG for a full list of changes). Support for MySQL has been added to the Data library. New Crypto and Zip libraries have been added. The build system has been revised, and the POCO C++ Libraries now work with GCC 4.3 and Visual Studio 2008.

And now let’s work full steam on the 1.4 release!

I finally decided that’s its time to show how one can use the WebWidgets library. The previous sample in the ExtjS/Samples directory is, well, I am not sure if it deserves to be called a sample
So if you wanted to take a look at WebWidgets and learn how to write your own WebGUIs, I’d recommend to start with the Picross sample (see here for an explanation what Picross is).
The implementation is rather simple (ie trading features for simpler and easier code). A sync to svn trunk is required, start the Picross sample, then open your web browser and point it to the location at http:/localhost:9980.
Feel free to extend it into a fully fledged application. For example, try to add two Images to the left, upper part of the grid, which allow you to switch between “mark as selected/mark as empty” mode. Currently only mark as selected is per default supported.

I just couldn’t resist and preordered one of those.
Now I just have to wait till end of November, then we can add the Pandora as an official POCO build target

As of revision 896 the POCO sourceforge trunk features a new class: the NullMutex (Poco/Mutex.h)

You now probably ask yourself: What’s so special about this class? Because - as the name suggests - it does nothing.
And that’s exactly why we needed it. Mostly all components of POCO are thread-safe. While this is generally a good thing, it also hurts performance when this thread-safeness is not needed.

The first classes to profit from this feature are all the classes from the caching and the events framework.

Events now have a second optional template parameter (which defaults to FastMutex) which allow you to specify the mutex. To disable thread-safeness for an event write:

Poco::BasicEvent<int, NullMutex>

The caching framework can benefit even more from this extension. Inserting an value into the cache requires a lock for the insert and then another lock when we fire the add event! In a full multithreaded environment all these locks are needed but what if you don’t care about the events at all and never register to them? Write

Poco::LRUCache<MyKey, MyValue, FastMutex, NullMutex>

to disable thread-safeness for the caches events only.

To additionally disable thread-safeness for the cache, write

Poco::LRUCache<MyKey, MyValue, NullMutex, NullMutex>

And if you don’t care about the mutex stuff at all? Then write

Poco::LRUCache<MyKey, MyValue>
Poco::BasicEvent<int>

as you used to do prior. The event/cache extensions are backwards compatible. When you don’t specify a mutex, a FastMutex is used per default.

I am happy to announce that the first release candidate for the upcoming 1.3.3 release is now ready. Those of you wanting to get a glimpse at it can download the tarball from here. The list of changes (over 50 bug fixes and enchancements) can be found here. Feedback is appreciated before we release the final 1.3.3 next week.

As those of you following the mailing list have probably noticed, a lot of bug squashing goes on currently. The reason is the upcoming 1.3.3 release, for which we’d like to fix most of the currently reported issues. The release candidate should be ready next Monday (Sept.22), after some more Data testing by Alex the final 1.3.3 release should be out one week later.

Part I of DynamicAny article just got published in the August issue of ACCU Overload. Part II is coming in October issue. Enjoy and stay tuned.

This is a request for comment about the future of POCO project*.

The POCO project team is soliciting feedback on the project itself, the development model, maintenance, releases and any other topic regarding the POCO project state of the affairs.

The current state of the project has some troubling aspects associated with it that we would like to rectify as soon as possible. In order to do that, we need your help. The development of POCO, as it currently stands, mostly depends on voluntary contributions. An obvious consequence is that we are not able to realize the plans as we would like to. While we are definitely grateful for any contribution, we feel that a project like POCO deserves better than that. Also, contributing a chunk of code is not the end of a contribution process. As written in a recent blog post, there’s much more to it and someone has to take further steps in order for the contribution to find it’s way into a release.

Given that the project already has a significant number of commercial users, we would especially like to encourage response from those entities in order to learn whether there is any interest in setting up an entity or a relationship overseeing the development of POCO. An example of “entity” would be a non-profit organization (e.g. Mozilla Foundation). An example of a relationship would be a sponsorship of POCO project or commercial support contract set up in a way similar to that of SQLite or a membership association similar to the SQLite Consortium. Additionally, we also encourage individuals, hobbyists and open source projects developers to respond with ideas and suggestions regarding this issue. Last but not least, the POCO Project page has a PayPal donate link, so please consider donating to the project as well.

The bottom line (and the reason for this request for comments) is, we would like to be able to have someone officially and professionally responsible for POCO project dedicating it certain amount of time every business day. This would initially likely be one person on a part-time basis, but depending on the interest, responses and establishment of said entities/relationships, it would eventually grow to full-time and more people. Needless to say, this would significantly improve the quality of the framework, the speed at which bugs are being fixed and releases published.

Here are few questions:

* Would you be willing to support POCO financially?
* Would you be willing to contribute the time of your employees?
* Are you in favor of non-profit entity and under what conditions would you join?
* Would you be willing to buy commercial support?
* Do you have any suggestions about the future of POCO project?

We feel that this is crucial for the future of POCO. If you like what we do and benefit from it, please consider responding. POCO is and shall remain free as both speech and beer. Regardless of the responses, the current project team shall continue doing its best to keep the project alive and healthy.

Thank you for your time.

POCO Project Team

* Anyone interested in any way, shape or form is encouraged to respond, publicly or privately. Should you require confidentiality, it will be fully guaranteed. In the latter case, send your comments to poco at appinf.com.

Generated using David A. Wheeler’s ‘SLOCCount‘ from current SVN trunk, rev. 661:

---

SLOC	Directory	SLOC-by-Language (Sorted)
88328	Foundation	cpp=69772,ansic=18556
86109	Data	ansic=52596,cpp=33513
26193	XML	cpp=20424,ansic=5769
23916	Net	cpp=23916
11642	WebWidgets	cpp=11642
7680	Util	cpp=7680
3974	NetSSL_OpenSSL	cpp=3974
2244	CppUnit	cpp=2244
990	PageCompiler	cpp=989
922	ApacheConnector	cpp=922
486	release	sh=486
118	dist	sh=118
103	build	sh=103
29	contrib	perl=29

---

cpp:	175076 (69.27%)
ansic:	76921 (30.44%)
sh:	707 (0.28%)
perl:	29 (0.01%)

---

Total Physical Source Lines of Code (SLOC) = 252,734
Development Effort Estimate, Person-Years (Person-Months) = 66.65 (799.85)
(Basic COCOMO model, Person-Months = 2.4 * (KSLOC**1.05))
Schedule Estimate, Years (Months) = 2.64 (31.70)
(Basic COCOMO model, Months = 2.5 * (person-months**0.38))
Estimated Average Number of Developers (Effort/Schedule) = 25.23
Total Estimated Cost to Develop = $ 9,004,062
(average salary = $56,286/year, overhead = 2.40).

---

After crippled-C++ Symbian, Java-only Android and Objective-C iPhone platforms, finally some companies have seen the light and came up with LiMo.

Now we just have to wait to see the first POCO phone