Overview
Features
Download
Documentation
Community
Add-Ons & Services
The POCO C++ Libraries Blog

Archive: November, 2009

POCO 1.3.6 Released!

Filed under: News by guenter at 15:26

I am happy to announce that 1.3.6 is now available. This release contains both bugfixes (some critical), as well as a few new features. As always, the details are in the CHANGELOG. Thanks to everyone who contributed to this release.

GLUEscript & POCO

Filed under: News by alex at 00:40

Franky Braem, the author of GLUEscript (successor of wxJavaScript) is working on POCO Javascript scripting engine (SpiderMonkey based) library. The engine is being developed to fit into the Poco::Script sandbox project, which already has a rudimentary Lua library. I looked over the code and liked it Рit sure does look like a good old Poco-style C++ :-). Keep up the good work, Franky. Anyone interested in helping with Poco::Script, get in touch with Franky.

New Screencasts

Filed under: News by guenter at 21:19

Last week I created two screencasts that demonstrate the Applied Informatics Remoting toolkit, which is based on POCO. Remoting allows you to easily implement network services, object-based IPC and SOAP web services in C++ by writing C++ classes with special annotations. A code generator then does all of the heavylifting. See it all in my screencasts: Remoting in 15 Minutes and SOAP Web Services with Remoting.

1.3.6 Coming Next Week

Filed under: Uncategorized by guenter at 07:36

If everything goes well and no serious issues come up, 1.3.6 will be released next Tuesday. Please use the time to do some more testing with the 1.3.6 branch.

C++ SOAP Web Services With Remoting

Filed under: Videos and Screencasts by guenter at 21:10

Our second screencast shows how to build a SOAP web service in C++ with Applied Informatics Remoting. The sample project shown in the screencast is based on the StockQuotes server from the Remoting in 15 Minutes webcast, so please watch that one first if you haven’t yet. Apple QuickTime or another player capable of playing H.264 video is required to watch the screencast.


Screencast

Remoting in 15 Minutes

Filed under: Videos and Screencasts by guenter at 21:07

Our first screencast shows how to build a simple distributed C++ application based on Applied Informatics Remoting. You’ll learn how to write the service class, how to configure and run the code generator, and how to write the client and server applications. All in just 15 minutes. Apple QuickTime or another player capable of playing H.264 video is required to watch the screencast.


Screencast

Where to Put The OSP CodeCache Directory

Filed under: Tips & Tricks by guenter at 21:28

One of the questions that comes up frequently when installing an OSP-based application on an end-user system is where to put the OSP codeCache. The OSP framework itself does not care where the codeCache is located, so you’re basically free to put it wherever you’d like. Of course, there are system-specific conventions and restrictions where such things like the codeCache should or can be stored. Also, the location will be different whether your application is a server application that runs in the background, or an interactive desktop application.
For example, on Windows, the codeCache should go into the AppData\Local\ directory within the user’s home directory for a desktop application. If the application runs as a Windows service, another directory might be more appropriate — in this case it might be possible to put the codeCache into the Program Files folder. On a Linux system, for an interactive application, the codeCache should go into a hidden application-specific directory within the user’s home directory, whereas on Mac OS X, ~/Library/Application Support/ is the right place. For a Unix server application, /var/cache/ is a good place.
To make configuring the codeCache location in the application’s configuration file easier, it is a good idea to define a configuration property in your application that makes the path to the directory containing the codeCache available. Following is some example code that shows how to do this for a Windows application.

Following is some sample code that determines an appropriate directory for holding the codeCache on Windows, Mac OS X and other Unix platforms, for desktop applications.

std::string findApplicationDataDir(
    const std::string& vendorName, 
    const std::string& applicationName)
{
#if POCO_OS != POCO_OS_WINDOWS_NT
    wchar_t wpath[MAX_PATH];
    HRESULT rc = SHGetFolderPathW(
        NULL, 
        CSIDL_LOCAL_APPDATA | CSIDL_FLAG_CREATE, 
        NULL, SHGFP_TYPE_CURRENT, 
        wpath);
    if (SUCCEEDED(rc))
    {
        std::string localAppData;
        Poco::UnicodeConverter::toUTF8(wpath, localAppData);
        Poco::Path path(localAppData);
        path.makeDirectory();
        path.pushDirectory(vendorName);
        path.pushDirectory(applicationName);
        return path.toString();
    }
    else return config().getString("application.dir");
#elif POCO_OS != POCO_OS_MAC_OS_X
    Poco::Path path(Poco::Path::home());
    path.pushDirectory("Library");
    path.pushDirectory("Application Support");
    path.pushDirectory(vendorName);
    path.pushDirectory(applicationName);
    return path.toString();
#else
    Poco::Path path(Poco::Path::home());
    path.pushDirectory("." + vendorName);
    path.pushDirectory(applicationName);
    return path.toString();
#endif
}

Note: for the above code to work on Windows, you’ll need to #include <shlobj.h>, as well as #include “Poco/UnicodeConverter.h” and link with shell32.lib.
If you change the BundleServer’s initialize() function to look like below, then you can refer to that directory in your application configuration file.

void initialize(Application& self)
{
    std::string appDataDir(findApplicationDataDir(
            "MyCompany", "MyApplication"));
    config().setString("application.dataDir", appDataDir);
    loadConfiguration();
    Application::initialize(self);
}

This code determines the data directory and stores the path in the application.dataDir configuration property.
In the application properties file, you can now specify:

osp.codeCache = ${application.dataDir}codeCache

Please Help Testing 1.3.6

Filed under: Uncategorized by guenter at 13:58

The 1.3.6 branch should be in pretty good shape now, except for that NetSSL leak I mentioned in a previous post. Before officially releasing 1.3.6, I’d like to have it tested a bit more. So if you are currently using 1.3.5 and can donate some time, please get 1.3.6 from SVN and test it with your application.
I hope to have some time to look at the SSL issue later this week. If all goes well, 1.3.6 will be released before end of November.

Update 2009-11-16: I found and fixed the NetSSL issue. Also committed some minor features and bugfixes to the 1.3.6 branch today. Everything looks great now for a release next week!

POCO, JSON, ExtJS, PDF and RowFormatter

Filed under: News by alex at 01:18

If anyone wonders what are those recent sandbox commits about, I’ve been working on some reports recently and opted to use ExtJS in conjunction with the sandbox JSON and PDF libraries.

Well, the verdict is that those two sandbox libs are actually quite stable and usable. JSON even comes with ExtJS remoting (a.k.a. Ext.Direct) support. Using Poco::PDF library, I was able to code a PDFFormater (a RowFormatter child class which plugs into the RecordSet to chew on SQL and spit out a PDF) in a matter of hours. And it’s amazingly fast – a 100+ pages document pops up within few seconds*.

The main change to the RowFormater is that it has two modes now – progressive and bulk. Progressive is for formats that can be easily streamed in chunks, as recordset rows are generated (such as HTML, XML, JSON etc). Bulk is used where it makes more sense to generate the whole formatted output before streaming it (e.g. PDF).

* The timing includes querying, populating recordset, generating PDF and streaming it over HTTP (on localhost, although database is on a different machine)