znPlugin 0.95 complete

Well, I haven't had much chance to work on znPlugin for a while, but version 0.95 is done. The reason this is not version 1.0 is that I am still looking for ways to optimize the code in accordance with my use cases. However, it has turned out quite well.

As I referenced in my last log, I had a good discussion with gneverov on http://cs.hubfs.net/. Near the end, you see a function posted that I wanted to incorporate into my code. However, that will no longer be possible because I have turned the Plugin Manager into a plugin factory. Thus, instead of creating and keeping objects around that may never be used, I create them on demand. The way I see it, if a user wants to get access to a previously created plugin, they should keep it around. Otherwise, they can always request a new copy.

I've also updated what constitutes a possible plugin, by making explicit the idea that it can be nested, as long as it is public. In addition, the implicit idea that a plugin must have a default (no arguments) constructor has been made explicit. While I abhor even putting such a restriction on my clients, it greatly simplifies the code and reduces complexity (and the possibility of errors).

Hopefully, I can find somewhere to put up my code. Preferably, somewhere with a SVN or CVS repository. I've thought of Sourceforge, but have had bad experiences in the past. If anyone knows of a good, and, for now, free, host, please feel free to leave a comment.

znPlugin update -- discussion on hubFS

I've initiated two discussions at hubFS (Post 3806 and Post 3786) on some aspects on znPlugin. Specifically, the parts that relate to performing efficient type comparisons and casting. There are a lot of ideas in that thread, including some sample code. Post #3875 is particularly significant, as it is responsible for the latest changes in the framework.

The discussions have slowed somewhat, but they are still good reads for people interested in Reflection within F#.

znPlugin -- generic plug-in library

As I mentioned earlier, znPlugin is a generic plug-in library that allows developers to add such functionality to their applications / libraries without forcing them to conform to any pre-defined interfaces.

Some competing libraries / frameworks are listed below:
  • MSINC .NET Plugins Library - A library, written in 2004, that does exactly what I am trying to do. I've been going through the documentation, and it provides some great ideas of how to reach my goal.
  • MSDN article - Food for thought on what needs to be taken into account when writing a robust library.
  • TechRepublic - Use C# and the .NET Framework to develop your own plugin architecture
  • Creating a Flexible Dynamic Plugin Architecture under .NET - They use XML files to store plugin information independent of the actual assembly. I did not opt for this approach, as it is extremely cumbersome to maintain an independent file unnecessarily.
  • Task Plug-in: A Flexible .NET Plug-in Architecture - A good introduction to elementary plug-in architectures.

I have already finished this library, for the most part. The only things left are to wrap the unsafe sections in try / catch blocks, perform testing and write some more documentation.

znOptions / znConfig update

Well, it's been a while since I've posted. First, some changes:
  • znOptions has been renamed to znConfig.
  • The library has been redesigned to support more than one options style platform.
  • Instead of hard-coding the save formats, I will use a plug-in architecture (more on this later).
Second, I have found some additional resources that have provided additional inspiration and ideas:
  • Nini - As per the description, "Nini is an uncommonly powerful .NET configuration library designed to help build highly configurable applications quickly." Though I haven't used this library, reading the documentation seems to hold this up.
  • libconfig - The description states, "Libconfig is a simple library for manipulating structured configuration files, like this one: test.cfg. This file format is more compact and more readable than XML. And unlike XML, it is type-aware, so it is not necessary to do string parsing in application code." The type-aware part is interesting, though I've no intention of looking at the source code so I will be coming up with a solution for that independently.
  • Elektra - Specifically, the backend page gave me some ideas about databases.
I was half-done with znConfig when I came across Nini. Looking at the documentation, I realized that it was what I wanted to implement when I came up with the idea in the first place. As such, I also remembered another library that I was supposed to implement first: znPlugin, a generic plug-in library.

As such, development on znConfig has temporarily ceased until znPlugin is done. Please see the next post for more information about znPlugin.

NOTE: In case there is any question, I am not reading/downloading/studying/... any source code from any of the libraries mentioned in my posts (save for the MSDN reference code). The whole point here is to learn about F# through implementation ("learn by doing", and all that).

znOptions -- application options file library

Here is the first problem I want to tackle. I have, as yet, been unable to find a good options save/load library to manage application settings.

On the flip-side, I have found a very interesting post on MSDN describing exactly what I want to do. However, I have no interest in using the registry and aggressively advocate self-contained cross-platform projects (think Mono and Portable.NET). Thus, I will use the second method described on that page in order to create a more functional way to save and load settings while hiding the details from the developer.

Interestingly, there is an OCaml library named config_file, part of the Cameleon2 system, that does something exactly like this. The primary reason not to use this (other than it being the easy way out) is to learn more about F#'s interaction with the rest of the .NET API and to learn a little more about .NET's XML manipulation capabilities in the process.

Thanks and regards.

znProjects -- First post

Well, this is my first post on this blog (my first blog!). Hopefully, I can use this site to document my progression through learning and using F# and OCaml.

Feel free to browse the links on the right, especially the News and Comics sections. You can never be too well-informed or have enough to smile about :).

Have a good day!