Server functions should not decode by default. Consider removing decoding option from various functions, providing appropriate wrapper(s). Also consider KP removal option.

[metabench]

Some of the functions have become longer and more complex than they should be, The options of decoding and removing the key prefix take up quite a lot of lines of code. There is also the issue of different sensible defaults for different functions.

In many cases, the un-decoded results are optimal, and some operations would work quicker on that data. Also, if the data is about to be transmitted then it's best to keep it encoded rather than go through a decode then encode process unnecessarily.

In some cases, decoded values make for the best and easiest to approach API.

Having a base layer that does not decode, and necessary decoding layers makes sense.

Client-side: can have a subclass that only returns decoded data unless encoded is particularly specified. Generally the programmer will want to access decoded data an ignore encoding to a large extent. In other situations the programmer will want to access encoded data. There are also different levels of encoding, such as a page of data being encoded, but it undergoes some decoding to split it into different encoded items.

Server-side: With the web interface, will generally only send and receive encoded data, and with functions that carry out some amount of processing or selection, that can take place on the encoded data. Some server-side functionality is likely to make use of decoded data too.

KP removal is an option which it is nice to have done server-side, but don't want to have to complicate the code much by having it. That is why a remove_kp observable processor will work well. KP removal would be down to code closer to the 'send' function rather than within generation of results.

Can make it so that a results observable can carry out the decoding or processing such as kp removal.

[metabench]

Have made good progress with this, still more to do.

[metabench]

It's worth considering what the core API is, if it differs from the ll API.

On a lower level, the client needs to obtain the results in a different way, with different ll tech. It could still show the same core API.

Generally, all the core functions will be available on the server and made available to the client, and in between there are components that handle communication. There is becoming less of a need to differentiate between ll and non-ll versions of functions, but I am wary of eliminating them.

The code has moved away from rows with their key prefixes removed. Though it saves memory, logically it's easier to structure code so that the rows always have KPs if they exist.

The capability of the Model to act as a bridge between buffered data and the logic of the DB is helping to simplify code in both the client and server components.