[Metakit] Starting work on a Java version of Metakit

[Jean-Claude Wippler]

gary.h.merrill at gsk.com wrote:
[... to java or not to java ...]

I respect your concerns.

> I can well imagine that relatively direct Java access to Metakit  
> databases would be welcomed by a significant number of Java  
> developers.  I encourage this effort.

Me too.  And if there is someone out there who wants to create a  
binding for Ruby, R, PHP, Perl, Lua, C#, or any other language: I'll  
bend over backwards to help you succeed.  There are some recent  
developments which might substantially simplify that effort, so  
please contact me if you're interested.

Metakit has always been about *not* tying data formats to a language  
(as most serialized formats do), and not to a limited time-frame  
(i.e. maintaining compatibility and readability for the very long  
term).  Metakit's file format is the way it is for very strong  
technical reasons, but I have some self-contained pure-Tcl and pure- 
Python readers laying around if people cannot use the C++ bindings  
for some reason, so no-one can accuse me of pursuing a lock-in strategy.

Making MK data usable from many more languages is a long term goal.   
As I said, I welcome everyone who wants to help make that happen.   
Feel free to pass this invitation on.

On the topic of speed: I'm working on creating a more highly  
"vectorized" design for Metakit.  So far, this has not only  
demonstrated (in the lab) potential for more performance, it also  
means that it will make it less of an issue as to which "host  
language" people decide to work with.  The trend is towards making  
the real crunching happen in a smaller part of the code - which can  
be tweaked and tuned to no end, whether in C, machine code, vector- 
hardware, or even some existing high-performance library to hook  
into.  It's a bit like GUI's, every app today benefits from major  
advances made in the OS and video driver and video hardware and all  
sorts of GPU's.

-jcw