On 4/27/20 10:03 AM, Brian Padalino wrote:
> On Sat, Apr 25, 2020 at 8:13 AM James Kulp <jek_at_parera.com
> <mailto:jek_at_parera.com>> wrote:
>
> I'll put forth a more restricted answer. The ACI can read volatile
> property values of all types, whole and in part.
> In all cases you can get the value returned as a formatted string
> according to the documented textual format.
> When the values being read (whole or part) are scalars or
> arrays/sequences of scalars, they can also be read directly as binary
> values.
>
> These restrictions come down to the fact that OpenCPI does not
> perform
> data type code generation for the ACI.
>
>
> Sure - that's very understandable.
>
>
> One idea that has been floated is to use Google's flatbuffers for
> this
> purpose.
>
>
> I won't comment on the binary reading part, but I would definitely
> recommend changing the string data exchange format to be JSON instead
> of what you have. There is a great JSON library for C++11 which makes
> super easy to use objects and is MIT licensed:
>
> https://github.com/nlohmann/json
>
And then all the yaml devotees will start complaining! IWBNI there was
a single textual format for everything we have. Currently our repo has
4....(XML, YAML, JSON, property-value).)-:
> Now, for something back on topic. I had setup the readsync
> functionality, but forgot to set it to volatile. When I did this, the
> read() method was called for syncing, but the data was never updated.
> Is this expected behavior? I would think that readsync would imply
> volatile. Are there cases where readsync would be set, but volatile
> shouldn't be assumed?
It is expected since you never said the value would change.
Having a readsync imply volatile is sensible, but a bit magical.
It would also eliminate the functionality of a readsync on non-volatile
values (i.e. tell me when it is accessed even if I won't change it after
start).
I.e. it would make the two issues tied together rather than independent
of each other.
>
> Lastly, there's a lot of XML happening for all these different
> devices, workers, platforms, etc. Is there a comprehensive XML schema
> that can be referenced for each of the XML data types?
Since we use a very compact runtime parser for XML, it was not ever
attractive to have that parser be schema-driven, since that would bloat
it, by 2 orders of magnitude last time we checked.
Even if there was a schema, it is far from sufficient for knowing
whether XML is correct, so there is always more validation that must be
coded separate from the schema.
And schema-based parsers cannot provide semantic errors.
That being said there are three pretty clear deficiencies in this area:
1. Some people want it to all be yaml, and some want it all to be json :-)
2. There is no simple standalone validation tool in OpenCPI - you have
to "build" and get errors.
3. The syntax-level (schema-level) error reporting is not great.
>
> Thanks,
> Brian
Received on Mon Apr 27 2020 - 20:03:16 CDT