Enhancing SSCXML and it's future

Ok,

as promised I'll talk about the missing stuff in the new data module. But I have a second topic that I'ld like to mention... but that's for later on.

So, if you take a look at the saturday's blog entry, you'll have a little idea of how the new data module interfaces will look like. They're neat, they're simple, they're incomplete...

In fact, an entire interface is missing. Here's why: When you're working with data value whose type is non-specific as expressed through the IDataValue interface, you cannot simply make a "new something" call. In fact, you'll need a factory that is able to create the data value of the type you need. Therefore a IDataValueFactory interface is needed.

My current definition looks like this:

class IDataValueFactory
{
 /** \brief Access the number of types this factory can create.
 *
 * \return value containing the number of types.
 */
 virtual size_t getNrTypes() const = 0;

 /** \brief Identifies the indexed type of the data value that can be created using this factory.
 *
 * \param Index to the type identifier string to retrieve.
 * \return a string containing the identifier.
 */
 virtual const ScxmlString& type(unsigned int _index) const = 0;

 /** \brief Checks if the type of the data value can be created using this factory.
 *
 * \param a string containing the data value type.
 * \return true, if the type can be created using this factory.
 */
 virtual bool canCreate(const ScxmlString& _type) const = 0;

 /** \brief Create a new data value of the given type.
 *
 * \param a string containing the data value type.
 * \return Pointer to the data value created using this factory.
 */
 virtual IDataValue* create(const ScxmlString &_type) = 0;

 /** \brief Destroy the data value.
 *
 * \param Pointer to the data value to destroy.
 * \return true, if the data value has been destroyed by the factory.
 */
 virtual bool destroy(IDataValue* _value) = 0;
};

In my opinion, any factory should be able to create more than only one data value type. This makes sense because you don't want to implement one factory for every data value type you want to support. So, the first 4 functions enable the user of the factory to check which data types are supported by the factory. Again this is entirely based upon strings to facilitate the usage.

The last two function create or destroy a data value. I think that for a clean structure, the one who has created an object is responsible for it's deletion. Simply incoke the factory's delete function and that's it.

Now, using the factories themself might be a little painful because you'll first have to get the right one and then make the create/destroy call.

So, I enhanced the interface of the data module by some functions: addFactory, removeFactory, createValue and destroyValue. Basically the developer is able to create his own factories, add them to the data module and create or destroy data values through the data module... hence everything data related "flows" through the data module.

One last thing I did was to add a clone function to the data value which might come handy when managing variables, creating copies, etc.

I still have to verify some of the interface functions to see if and how well they work together with a separate script implementation (remember: data management and scripting language linked together).


So far so good.

Now the other thing: The future of SSCXML.

I admit that, although I hoped otherwise, I didn't sell any license of SSCXML. I had some companies showing interest, some people asking questions but it didn't start off as I had hoped. Although the possible application fields are widely ranged, the interest itself was (and is) quite low.

SSCXML was the first publicly available implementation in C++, having a very easy to understand and very easy to use interface structure. It doesn't cost anything as long as you don't develop a commercial application using it and if you do, the price seems to be ok to me for the work that has been put into it (and the time you save when using it). Although these advantages, it just didn't pull off.

Now, almost a 9 month after my beta testing session and the launch, I've seen Qt (aka Trolltech/NOKIA!!) implement a SCXML lib into their Qt library. As far as I have learned, there have been several people working on it (while I was working alone), they're talking about some stuff I have on my road-map (ie. visual editor) and their google hits are higher (I suppose it's due to Qt overall higher presence and their tags on their webpages).

While my implementation is quite free from any library that must be available to use it, the Qt SCXML implementation is very bound to the Qt library itself.

So, now, seeing all this, I'm wondering what I should do. The product doesn't sell, the user base isn't high (tending to a handful of people coming and going) and so is the feedback I get.

I have several options:

1. I keep everything as is and I change nothing. I keep the business model, I continue development at my own speed (taking user requests into account as fast as possible) and hope that both, the user base and the licenses, will rise.

2. I make it completely open-source handing out the source code, scratching any idea of it being "my baby" and let an eventual user base take over the control.

3. Make it in a Qt similar way: under dual licensing handing out the complete source code but people have to pay to make commercial usage. This actually is almost the same way I do it now, except that I keep the source code closed.

4. Keep the source code closed and hand them only to those who pay for it. The non-paying people can use it for free.

5. Make it "donation" soft or "donation" open source... however you might want to call it. Hand out the source code, taking some people into the team who would like to contribute and ask for some money which is spent on material (books, hardware, etc).

So my question to you is: Which option would you use? Or do you have another suggestion?

Thanks,
Stefan