Currently UOAI is not compatible with the latest client patches, the callibration routine crashes, which is probably the source of most errors observed in the last few months; even though i haven't spent any time looking into it yet.
This leaves UOAI in a broken state; i will however fix the callibration routine next weekend.
After that I will start spending time again on UOAI development; but development will be slow, i will only work on it during weekends. And from now on i'll try to work in a slightly more organized way (as far as I'm capable of that
). One major issue during development of UOAI up to now is that I have more ideas than I will ever find time to implement; ... if I keep that up UOAI will be in development for ever. As a result i will focus right now on developping a version of the COM library only, that will basically just fix all currently known issues, even though i will rebuilt it from scratch. After that I will solely focus on maintaining compatibility with newer client patches. I will no longer spend any time on the wrapper or developing a .NET version of UOAI as I first planned to do, but maybe Arul or anyone else will keep that part alive for me.
The reason to redesign from scratch, is partly just because i feel like i need a clean start on UOAI, but also results from the fact that I have been working on this now and then as part of a project unrelated to UOAI: In the research institute I work there is a huge 'software-mess' as I like to call it. Experimental setups are typically using a lot of special-purpose devices that can be controlled by some text-based protocol through a bus system (typically GPIB). These special-purpose devices are often moved from one setup to another, and each experiment might require a different combination of devices. It would therefore be interesting if the software (drivers) controlling each device is 'pluggable', so that you can assemble the sofware you need for a specific experiment by just using the right combination of drivers, and code a small macro or sequence to do the required data-collection. In one part of our lab there has been a consistent set of rules on how such a driver program should work to make it 'interchangeable'; but these rules are limited and quite outdated (based on sharing data through DDE, even including some components that date back to the 16bit-era, running only on f.e. win95
). Also other (parts of the) labs in the institute don't stick to these rules at all. The result is that very often software is just completely rewritten whenever a new experiment is started. We wanted to address this problem, and my idea is to address it by requiring the drivers to be COM-components, and by defining fixed interfaces for devices with the same purpose (basically this means the same as requiring the COM objects for one class of devices are inherited from the same object class). That would result in perfectly interchangeable and pluggable code,... but it would also complicate software development... not everyone would be able to quickly write a driver in the form of a COM component; some people here are limited to assembling a program in a graphical language like LabView.That's why i wanted to redesign my COM subsystem to allow easy building of COM components. The idea was to use an extension language (f.e. LUA) and build an IDispatch implementation to expose interface implementations written in LUA. In combination with software that can generate LUA code automatically and assemble a stand-alone assembly from your LUA interface implementations; it would be really easy to write such drivers. So basically what i'm working on right now is a redesign of my COM subsystem to allow a wide variety of interface implementations to be exposed; including the LUA part. Also correct error-handling and self-registration and signing is addressed in the newer version.
From there i have a choice, when it comes to UOAI: either i use a C implementation of the UOAI interfaces, or i implement everything in LUA. The last choice would make it easier to extend and change UOAI; but i'm not sure about the resulting performance hit. As however the LUA code would get loaded and compiled whenever UOAI is started it might actually perform quite well. Note that other extensibility languages can be considered... but LUA seems the most obvious choice.
(Extra Note... I later on also noticed that the idea for a software framework based on COM in our lab is not new: the IVI foundation already came up with exactly the same idea before me; and they worked out every single detail... see http://www.ivifoundation.org/ for the interested!)
Greetz,
Artaxerxes
. I think if you want to join the UOAI2 (vb.NET) part it's best to talk to megamandos too...