It would be useful to allow iteration over entries of a trie -- TrieDumper already implements this for simple output, but this would have other uses as well, esp. converting to other data structs.

Given that internal storage is nothing like that for Maps, the primary interface should NOT be Map's iterator (that would give wrong ideas of optimal usage), but for compatibility it is possible to also provide access as Map.Entry instances (for JDK Maps this is optimal interface because entries returned are part of Map; for trie there is no such internal structure to use).

Although current tr13 structure is fundamentally immutable in some respects -- can not add entries for example -- it would be possible to add some forms of mutability.

And specifically, it should be possible to change value of an existing entry, iff length of value is not changed.

It might even be possible to allow deletion by some use of tombstones; although this is something application might be able to fake by regular changing of value, using some bit marker within value to indicate "has been deleted" condition.

Assuming uniform access, but non-uniform distribution of keys, it should be possible to order child nodes in decreasing order of size (ideally number of leaves, but serialized size should be close enough approximation), to reduce average lookup time.

I'm loading up a tr13 into a byte buffer then attempting to use it from a memory mapped byte buffer and getting errors attempting to lookup values I put in the tr13. It isn't even very large yet. It appears to be attempting to pull up a value which is much larger than the generated file itself.

Here is the exception:
Exception in thread "main" java.lang.IndexOutOfBoundsException
at java.nio.Buffer.checkIndex(Buffer.java:532)
at java.nio.DirectByteBuffer.get(DirectByteBuffer.java:253)
at com.ning.tr13.util.VInt.bytesToUnsigned(VInt.java:165)
at com.ning.tr13.impl.bytes.ByteBufferBytesTrieLookup._findValue(ByteBufferBytesTrieLookup.java:81)
at com.ning.tr13.impl.bytes.ByteBufferBytesTrieLookup.findValue(ByteBufferBytesTrieLookup.java:36)
at MemoryMappedLookup.testString(MemoryMappedLookup.java:174)

Any thoughts it I'm somehow causing this? There is quite a lot of code to try and post a small sample. I will try and cook up something if this doesn't ring any bells with anybody.

It would be nice to be able to combine build-in-memory, and creator of trie into one step, to be used for cases where disk-backed version is not necessary.

For this I can use ByteAggregator from StoreMate (or other projects I use it on).
Its benefit over ByteArrayOutputStream is that there's no need for constant reallocation, copying, as it is segment-based. This helps with GC. Plus it could even use off-heap buffer segments if that seems necessary.

Current API is half-baked (if even that much); implementation details leak through, and it has preference for using Strings (which is wrong).
Need to redesign; can result in incompatible changes as necessary.

Given iterator functionality (see http://github.com/ning/tr13/issues#issue/2), it should be easy to implement merge functionality, where 2 (or perhaps more) input tries are merged into a result trie.
This assumes that tries are ordered the same way (meaning usually they are not reordered).

Functionality would be most useful for incremental building of tries, for example in (near) realtime cases where mutable HashMap (or such) is used for gathering new entries, which are regularly merged with immutable tries instance, to produce new immutable version.