Skip to content

Implement declarative payloads.#300

Closed
albu-diku wants to merge 1 commit intonextfrom
addition/declarative-payloads
Closed

Implement declarative payloads.#300
albu-diku wants to merge 1 commit intonextfrom
addition/declarative-payloads

Conversation

@albu-diku
Copy link
Copy Markdown
Contributor

Add the logic to automatically package values as a bundle that is formally named. Such a bundle remembers its type, can be validated and provides the facilities allowing its serialisation and deserialisation.

In terms of utility, such a construct allows us to capture a particular grouping of values that belong together and is intended as infrastructure for cases where indirect calling is necessary e.g. programmatic accesss to a JSON API where a client and a server API must exchange strucrured data.

The conditions needed to declare a payload "valid" live with its definition thus any set of values can be immediately tested for validity. The code used to perform the checks is is the existing validation functions, thus there is an upwards path for adoption in existing code.

Use this as the mechanism by which payloads are checked for validity. As part of declaring a bundle definition the expected positional arguments are declared so implement basic length checks that catch missing positional arguments which were required. Each argument itself is also tested aganst an optional validity function which can be specified at the point of definition.

Raise uniform payload exceptions when validation fails. Further, upon failure the exception produced can be serialised directly to JSON with useful messages about the failures that occurred, making it a useful both for the case of generating detailed user-facing reports on the command line as well as potentially reporting errors against fields with UIs.

Add the logic to automatically package values as a bundle that is formally
named. Such a bundle remembers its type, can be validated and provides the
facilities allowing its serialisation and deserialisation.

In terms of utility, such a construct allows us to capture a particular
grouping of values that belong together and is intended as infrastructure
for cases where indirect calling is necessary e.g. programmatic accesss to
a JSON API where a client and a server API must exchange strucrured data.

The conditions needed to declare a payload "valid" live with its definition
thus any set of values can be immediately tested for validity. The code
used to perform the checks is is the existing validation functions, thus
there is an upwards path for adoption in existing code.

Use this as the mechanism by which payloads are checked for validity. As part
of declaring a bundle definition the expected positional arguments are declared
so implement basic length checks that catch missing positional arguments which
were required. Each argument itself is also tested aganst an optional validity
function which can be specified at the point of definition.

Raise uniform payload exceptions when validation fails. Further, upon
failure the exception produced can be serialised directly to JSON with
useful messages about the failures that occurred, making it a useful both
for the case of generating detailed user-facing reports on the command
line as well as potentially reporting errors against fields with UIs.
@albu-diku albu-diku marked this pull request as draft October 14, 2025 19:56
@albu-diku
Copy link
Copy Markdown
Contributor Author

This work attempted to add infrastructure allowing the naming of specified payloads - something like a user payload, a peer payload. The idea that input paths would then be able to state what they are accepting in a more declarative fashion.

I was never able to generate any interest around this. Meanwhile, the peers ui work ended up with a different approach - there, effectively, one provides something akin to a REST API and a series of routes that capture the decoding of an already particular set of data. That achieves some of the same goals, albeit losing the ability to trivially handle compound payloads (say, a user and a peer).

It is unlikely this will ever be returned to at this point so call time.

@albu-diku albu-diku closed this Apr 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant