Draft
Conversation
Previously, the module recursively looped and checked key in the iterable. It had a limitation that it could not handle mixed types, root array, and empty key. JSON Pointer solves this problem because it can address all points in a JSON object whether it is an array or a dictionary. See also: https://datatracker.ietf.org/doc/html/rfc6901 BREAKING CHANGE: Previous json field addressing will no longer work
this does not add anything that actually does anything with the configuration
By using config file, there is no more need to add additional argument when defining asyn address. Some comparison logic and parsing can now be simplified.
this additionally has reduced risk of memory leak, as addr is only allocated after all checks have passed.
essioc
force-pushed
the
feat-json-write-support
branch
from
fd3054f to
d8b9012
Compare
Some records prefer to have separate writable field.
I considered implementing topic like
AbstractTopicName
ReadAddress
WriteAddress
Template
Fields
However, this is problematic because when a message arrives, its topic
is the only name that is exposed. Therefore the searchable key for finding
the option must be in the same place as AbstractTopicName, not as a field
under it. (otherwise the search will be a bit more expensive)
So keeping the roles like:
ReadAddressAndAlsoTopicName
WriteAddress (optional)
Template (optional)
Fields
Seems more practical
Then, during config time the program can determine whether the record
ought to be writeable or not (absence of template = not writable)
this simplifies writing records that are supposed to be read-only
without having to write a dummy template just to satisfy the writer,
or having read only records that have ill-defined write behavior.
There are some duplicate code calls for some refactoring, but I don't see
a straightforward way to achieve this because callers for functions like
arrayWrite, integerWrite is not very modifiable, and adding a method that
prints status and returns error code doesn't really make the code shorter
or simpler
essioc
force-pushed
the
feat-json-write-support
branch
2 times, most recently
from
ed001e1 to
1cf5447
Compare
essioc
force-pushed
the
feat-json-write-support
branch
from
1cf5447 to
9e00eab
Compare
Collaborator
|
still WIP - but can you submit 25c64e8 (First commit here) in a separate PR, please? I support the change, but I think it deserves its own attention |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This changelist replaces existing JSON handling, by using JSON pointer to address components within MQTT JSON message and configuration file to provide templates and alternative write addresses.
List of changes: