[rfk-dev] possible enhancements

[leonardr at linux.ucla.edu]

> 2) NKIs should be seperated from the binary and kept somewhere like
> /usr/local/share/rfk/nki/.  Furthermore, it should be possible to have
> multiple NKI files.

I agree. I would also love to be able to load NKIs from a URL. I wouldn't
want to write that C code, though. Sometimes I toy with the idea of
writing a Python RFK that's easier to hack.
 
> 3) What does the version number reflect?

It has no meaning; it was a parody of the idea of version numbers in
general. The subversion number is obviously the number of NKIs, but in a
world where NKIs don't live in the binary and every possible string is a
potential NKI, it should be removed, or set to aleph-null or n or oo or
Ax(NKI(x)) or something.

Another possibility (I don't remember) is that the version number is so
high because I intended for the version number to run *backward*, each new
release having a lower version number and a higher subversion number,
until version 0.oo was reached. That would be would be the perfect
version, and at that point the software would achieve enlightenment.

Leonard
It's a tub of chitin chitlins.