Qualified vs Unqualified keywords

[jjttjj]

Currently qualified keywords are used internally.

They are needed for spec, and I thought I might be able to take advantage of being able to dispatch on a globally unique key with no further context in the same way that spec does for other features besides spec, such as transformation to and from values IB expects/provides, and extension points such as giving a default value to a request parameter, and things such as associating request types with response types and "ending response" types, so that synchronous request can be built upon this data.

Qualified keywords are unwieldy for an enduser to use.

Are they also to unwieldy to an implementer of extension points to use?

Should iboga be built on qualified keywords everywhere, and the unqualifying step be either built on top of this, and/or manually done by the user?

In order for the qualifying step to be opt-in, we would need to change the incoming message handler system so that handlers could be applied in an ordered manner. Or have the unqualifying handler be special, or just an option specified on client creation.

Alternatively, we could go in the opposite directions, and not qualify keywords as often internally, possibly only use them for spec. For example, default request parameters don't need qualified keys. Nested maps can generally replace a hierarchical keyword.

[jjttjj]

Currently, since our client unqualifies all incoming messages, all higher level functionality (for example, synchronous requests) must use unqualified keywords on the incoming message, but qualified keywords on the request, since we need our request to have defaults added, which currently depends on a qualified map. This doesn't feel right
For example:
https://github.com/jjttjj/iboga/blob/master/dev/iboga/wip2.clj#L59