Version 2.2.1 of Openwsman is now available for download at sourceforge.
2.2.1 introduces some major changes, esp. helping to confine memory
usage on embedded systems.

Version 2.2.0 of Openwsman is now available for download at sourceforge.

Note: This release will be followed by 2.2.1 within 4-6 weeks which will include further stability and 'corner case' fixes.

An easily browsable documentation of the bindings API is now available online.
This is automatically generated from the SWIG input files by Rubys rdoc documentation system. It uses an extension to rdoc tuned for SWIG files.

One thing that bothers me when coding against the openwsman client API is the amount of protocol knowledge needed. A simple enumeration call requires one to know about enumerate, pull and release. Not to mention keeping track of the context.
Having enjoyed the ActiveRecord pattern as implemented in Ruby On Rails, I collected some thoughts around using this for WS-Management client programming.

At the last Management Developers Conference (http://www.mandevcon.com), I presented my work on scripting openwsman server plugins. This is a way to write plugins in a scripting language, like Python, Perl or Ruby.

The attached presentation shows how the problem was approached and describes the implementation. Its in an alpha state currently and needs some more work to become fully functional. This will also require some changes in the openwsman plugin API to fully support plugins.

We are glad to announce the release of openwsman 2.1.0 which is a bugfix release that fixes some security issues and has various improvements, especially in the http stack and improved platform support thanks to many contributions from the openwsman community.

Openwsman 2.1.0 can be downloaded from sourceforge.

Committing revsion 2642 to the source code repository completed the buildsystem conversion to CMake today.

It now supports building and installation of all openwsman components (libraries, plugins, authenticators, include files, openwsmand).

Some numbers:
- total size of all Makefiles:
551018 for autotools
255517 for CMake
- total time spent for Makefile creations (from scratch):
26 seconds for autotools (bootstrap; configure)
2 seconds for CMake

Openwsman now (as of svn rev 2609) supports building with CMake (see www.cmake.org) as an alternative to autoconf/automake (also known as 'autotools').
The initial CMake support is limited to local builds on Linux, sufficient for development not a complete autotools replacement yet.

Openwsman 2.0.0 is planned for end of March. Beta 1 was released 2 weeks ago.

I know from many of you, especially those I talked to in person, that you might have some local changes to earlier releases fixing some issues and even adding some features. Some even promised to send patches and fixes, but nothing happened so far.

The python bindings are still very basic and cover just a few of the client features of openwsman, however, with just the limited functionality a lot can be done as can be seen in the newly checked in python code with CIM bindings.

The code can be found in subversion under the new sub-project pywsman. This is basically a simple wrapper around the bindings that full expose CIM data in a pythonic way. Code as simple as the following snippet yields useful data that can be reused in any python application: