Archive Page 2
After playing around with wxWidgets and trying out some ideas on a service handling interface, I decided to first do a quick solution that resembles the old NWNX2 GUI and supports only the interactive mode. That way, there is something out sooner, and I have more time to decide what kind of interface I really want for NWNX4.
To this end, I refactored parts of the controller source into a class, which can be used by the command line interface and the new GUI program alike.
The plugins and the controller program slowly loose their alpha-quality and are about to enter the beta phase. What is now needed for a first beta release is a graphical interface.
A break from working at the more low-level stuff will be nice. Yesterday, I started working on the GUI stuff, which will allow the creation and controlling of NWNX windows services. The design and functionality will somewhat resemble the MySQL Administration program, which has a clean interface and looks good, IMHO.
After a couple of weeks working with Ruby on Rails and SQL Server 2005, certain aspects slowly crystalize:
1. The ADO DB driver (which uses win32ole) does not work on Ruby 1.8.4 and 1.8.5. I can not help but wonder who besides me actually uses Rails and SQL Server 2005 ? It justs segfaults on the very first access. So: Do not use it.
2. The ODBC driver of ActiveRecord 1.14.4 does not like the way the SQLServer Adapter creates the requests of the paginator class (SELECT TOP 20 (SELECT …)). It just stops with an “argument out of range” error.
3. What actually does work is this combination: Ruby 1.8.5 + Rails 188.8.131.5218 (Release Candidate 1 of Rails 1.2), using the ODBC driver. The ODBC connection seems to be preferred over the ADO one, and with the latest changes to the SQL Server Adaptor in ActiveRecord 184.108.40.20618, the argument out of range error is gone as well.
4. Decimal columns seem to work fine now. Prior to the update, I had the problem that “1,5″ always got casted into “1.0″, maybe because the separator is a comma and not a dot in my case.
5. What still does not work: DateTime columns with dates prior to the year that the Ruby Time class accepts, so this change is necessary:
lib\active_record\connection_adapters\sqlserver_adapter.rb around line 105 (cast_to_datetime) and line 116 (string_to_time):
return Time.mktime(value.year, value.mon, value.day, value.hour, value.min, value.sec)
return DateTime.new(value.year, value.mon, value.day, value.hour, value.min, value.sec)
If the column is a DateTime, ActiveRecord should return a DateTime, IMHO.
Dates like 1754-01-01 14:00:00.000 work with this change. Note: 1753 is the earliest date accepted by SQL Server, and ActiveRecord really should accept it.
6. Since I have to work with a legacy database which uses ISO-8859-1 as encoding, the whole rails application has to use the same. Rails 1.2 seems to default to UTF-8, which e.g. breaks the truncate function when it encounters an Umlaut.
Fix: in environment.rb, add the following lines
# Include your application configuration below
# Set multibyte encoding to none.
$KCODE = "NONE"
Bottom line: Update to Rails 1.2 and use the ODBC connection for SQL Server 2005.
NWNX4 is making good progress !
As of today, there are two types of database plugins (SQLite and MySQL), and a nifty Timer plugin for accurate performance measures. There are lots of huge and small improvements everywhere. I am really exited about how nicely NWNX4 develops.
I’ve been through 4 prototypes now, each one adding a bit more functionality, with the last one quite a lot (MySQL support for example).
Linking against the mysql client library (which can be installed optionally with the server) became quite an adventure today. MySQL AB seems to use Visual C++ 2003, while I use the 2005 version. This leads to all kinds of nasty problems, effectively, you can not use their binary static library. I had to recompile it on 2005 to make it work. The upside is: MySQL versions 4.1 and 5.0 are equally supported by a single plugin !
These libs are needed for NWNX4:
You can just open the .sln file in the windows source package, let VS 2005 convert it, and then compile the mysqclient project. Be sure to use the correct configuration! “classic nt” worked for me, while the default “authent” results in a library that complains about the server beeing not the (commercial) enterprise one. Oh well.
I haven’t received my copy of NWN2 yet, so right now it is difficult to set a release date for the prototype (i.e. alpha) version. I think it is going to be in the next few days. It will not be a fully developed version with all the bells and whistles – but a functional prototype without a shiny GUI in the first few weeks.
The first database plugin (SQLite) is done and seems to work fine, although I did not get a chance to fully test it. Right after the first release, the plan is to continue work on the plugin interface, and after that is done, move on to the other plugins like SQL2005, MySQL, and so on. I plan to outsource some of those plugins, since I will not be able to do them all on my own.
I hit a small bump in the road today: The NWNX Controller can not pass information to the NWNX Hook using the nwserver command line. It (the server) just does not like unknown parameters and in turn fails to load the module (sic!).
I was planning to implement IPC (inter process communication) between the GUI and the Controller sometime later, but had to start on a prototype version between the Controller and the Hook today. A bit more complex than I would like it to be, but it works. A way to communicate between the Controller and the Hook was missing in NWNX2 anyway, so I am glad this is finally done.
The new plugin architecture is done. While still resembling the old one, the interface is a bit simpler to understand. On the feature side, it is now possible for plugins to provide a “function class”, independent of it’s DLL filename.
That means that e.g. several database plugins (xp_sqlite.dll, xp_mysql.dll, and xp_sqlserver.dll) can share the same function class “sql” and register it with NWNX. On the other side, a script always calls a function based on it’s function class, no matter what the underlying plugin is named, meaning that a request for a “sql” type plugin is routed to one of the installed plugins that provides the “sql” class.
A simple change, but one that provides much better flexibility than the old, rather monolithic, approach.
The hook of SetLocalString in the NWN2 dedicated server is done!
I did some work on the logging and command line parsing functions, as well as laying out parts of the new plugin structure. Basic grunt work on which I plan to build on.
Just three days before I’ll be off to vacation, I received the server executeable for NWN2. The framework around NWNX was already there, so I just had to add the hooking routines.
As soon as I get back (end of September), I’ll work on the database plugin and a beta version for people to try out.
After some time playing around with the FOX toolkit, I found the available documentation and examples are lacking a bit. wxWidgets is the next candidate for the NWNX GUI, and in terms of community support, looks considerably better.
There is a detailed document on how to set it up with VS Express.