[EMAIL PROTECTED] 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
_____________________________________________ Metakit mailing list - [email protected] http://www.equi4.com/mailman/listinfo/metakit
