On 4/27/20 4:05 PM, Brian Padalino wrote:
> On Mon, Apr 27, 2020 at 3:48 PM James Kulp <jek_at_parera.com
> <mailto: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
>> <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).)-:
>
>
> 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.
Sorry to make it overly complicated. There is
doc/xls/OpenCPI_XML_Attributes.xlsx
It is not up to date, but if you like it, perhaps it can be.:-)
>
> Thanks,
> Brian
Received on Mon Apr 27 2020 - 20:11:05 CDT