On Mon, Apr 27, 2020 at 3:48 PM James Kulp <jek_at_parera.com> wrote:
> 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> 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).)-:
>
I think my suggestion here was lost. I am not suggesting JSON be anywhere
else, but a getPropertyJSON() method would be nice. Right now it spits out
some formatted string which I have to write some parse method for as
described earlier by Davis. YAML doesn't make sense here, but JSON really
does.
> 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.
>
OK. Understandable.
>
> 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.
>
OK. How about a different way of asking the question.
The XML files are defined across a whole slew of documentation in many
different PDF's and not coherently.
Is there a centralized document which describes each XML entity with their
properties and what they all mean? Sometimes I get errors stating what was
expected when I don't type something that is expected. That's all I am
asking for. I don't care about validation. I just want to know what's
possible without having to look mostly at examples or 5 different PDFs.
Thanks,
Brian
Received on Mon Apr 27 2020 - 20:05:06 CDT