Reflections on lon nimi

I thought it to be in poor taste to describe the disgust with my work while I was also releasing it.

The lon mini service is quite unimpressive and barely does anything.  I decided to target toki pona,
when mulling over more interesting topics while driving, reasoning that it would be better for me to
finish something already.  I realized in the starting steps that toki pona is very uninteresting and
so bare that there's almost no information for such a service even to provide as answer to question.

The toki pona constructed language is largely made up of semantic primes, nearly making it unable to
describe any of itself, and it mostly retards rather than helps language work through its omissions.

I decided to finish lon mini anyway, rather than entirely discard it for my next work.  I understand
my Latin skills are too immature to comprehensively target it, but there are some subsets I entirely
understand, namely nouns.  My next work in this should be writing such a service targeting the Latin
nouns whose meanings I know; I've thought for so long about the representations and stored data that
would be needed for this.  Something useful I learned with the toki pona targeting is how bothersome
implementing intake of an Elision dictionary numerical format can be and, as I know not enough Latin
to design such a format properly, I'll use lesser formats and postpone the numerical format for now.

Still, even lon nimi is able to show the basic approach I intend to take.  The WWW interface uses no
explicit computation outside of the HTTP server; every possible answer is enumerated and a rewriting
rule translates to a static directory requests to what seems to be a program; additional rules allow
for infinity to be addressed by handling all cases for which an answer be not explicitly enumerated.
This makes the service trivial, easily maintained, and the HTTP server handles logging and the like.

Similarly, the UDP interface exemplifies the tabular programming approach, as opposed to that purely
passive; the dictionary holds all known words, which enables entering all mutations thereof into the
trie; the trie may be searched to convert from the letters to the Elision representation, which then
allows easily accessing any information about any word or word mutations; I find it to be beautiful.

I think my basic idea behind the UDP interface is far superior to IETF RFC 2229, A Dictionary Server
Protocol.  All kinds of answers have varying lengths, which enables a simple client to react to them
based only on length.  The answers are suitable for direct human use, but are still sent as records.
I considered offering WWW, UDP, and Telnet interfaces, but to me the last would be too much trouble.