Bosk should be extensible by the user

[prdoyle]

Bosk is presently extensible in one major way: the BoskDriver interface allows for extensible, composable behaviour for managing changes to the state tree.

I think a proper 1.0 version of Bosk ought to be extensible in more ways, probably using the Service Provider Interface (SPI).

Tree node datatypes

Bosk currently supports a certain fixed set of basic datatypes, plus anything derived from StateTreeNode. This means there's no way to add support for third-party data structures that can't be changed to inherit StateTreeNode. For example, we currently don't support the pcollections library despite the fact that our own data structures (like Catalog) are implemented using this library.

There are several difficulties with supporting extensiblity when it comes to node datatypes.

First, serialization and deserialization. This is the harder problem. It's not only a matter of serializing to JSON because, as demonstrated by MongoDriver, any driver can have its own built-in serialization (for MongoDriver, it serializes to BSON). This could probably be solved by supplying a mapping to/from other types that are already supported by Bosk, rather than having users directly implement serialization logic.

Second, instantiating objects of a given type. Presently, we have very specific requirements and restrictions on the exact form of the type's constructor: in short, it must work pretty much like a Java record. This is the main reason pcollections isn't supported: those types tend to be instantiated using factory methods. This problem isn't very hard to solve: one could simply supply a factory method/object that Bosk could call. Note that instantiation is required for both grafting and deserialization, though deserialization is (as mentioned above) part of a larger problem that would likely be solved a different way.

(One might ask: why do we require data structures to inherit StateTreeNode in the first place? That interface has no methods, and if some type meets all the other requirements, why must it also inherit StateTreeNode? The answer is not a strong one, and we might one day do away with StateTreeNode, but as long as we're uncertain, it seems easier to remove this restriction later than to add it later. The reasoning goes that StateTreeNode makes the user intent explicit; marks the corresponding class as being part of the bosk state, making the code more self-documenting; encourages people to have purpose-specific types for their state tree rather than using existing objects from their business logic; and makes the bosk implementation slightly simpler in some cases.)

Third: custom type validation. As soon as you allow new types in the state tree, validation must stop disallowing them!

Observability

Bosk presently has a lot of logging using SLF4J and could also offer a lot of metrics. We don't want to depend on, say, OpenTelemetry, so we should probably have a pluggable observability system with sensible defaults.

Newer Java versions

We should have strong support for features of newer Java versions, including modules. It's an open question whether we want to continue supporting Java 8. Ideally, the design of bosk would be flexible enough that support for newer Java versions could be supplied in additional supplementary packages; for example, bosk-java17 could automatically allow any subclass of Record, or could have special support for sealed types.

[prdoyle]

Took an initial step toward this in #81.