it should be possible to configure the parser with data

[bpsm]

I'm thinking of something like:

Parser p = Parsers.newParser(…);
Parseable r = Parsers.newParseable( … );
Parser.Config cfg = (Parser.Config) p.nextValue(r);

Where the Parseable r reads edn that's something like this:

#bpsm.edn-java/parser-config {
    :listFactory #bpsm.edn-java/class "fully.qualifed.class.Name"
    ;; new fully.qualified.class.Name() returns a CollectionBuilder.Factory
    …
    :handlers {
        :my/base64 #bpsm.edn-java/method {
            :class #bpsm.edn-java/class "fully.qualified.class.Name"
            :name "staticFactoryMethod"
        }
        ;; fully.qualified.class.Name.staticFactoryMethod() 
        ;;     returns a TagHandler.
        …
}

Open design questions:

• the example above makes heavy use of tags, distributing the work of parsing the configuration between the parser-config, class, and method tags. An alternative that leaves out the inner tags for brevity preferring instead to pack the knowledge into the handler for parser-config is conceivable.
• the prefix #bpsm.edn-java is just made up. Convention elsewhere in the code base is to use #info.bsmithmannschott, but that's rather long -- though it's certainly unique.

[mikera]

Nice idea!

I'm wondering if there is / should be an edn-wide standard for how these kind of tags are named? The edn spec isn't particularly specific - only says that the prefix should "must be owned by the user (e.g. trademark or domain) or known unique in the communication context".

In this case, since the domain is controlled, you can safely use any prefix you like if the spec is to be believed - e.g. just #edn-java/method would be fine I think.....

[bpsm]

don't intend to implement