The AllList holds parameters to aid deallocations, and to hold subparameters
during frame->internal conversion. The AllList plays no role in internal->frame
conversion.
During frame->internal conversion, all subparameters in the frame are placed on
the all list. Then an "assimilate" function places the subparameters on the
proper, specific member variables (like m_pROSpec). If a subparameter is not
recognized and, hence, there is no specific member to place it on, the
subparameter is still properly deallocated because it is on the AllList.
Order of subparameters is important for conformance. That's when the
internal->frame conversion is done by a function that uses the specific members
rather than the AllList. There is no constraint on order for things being in
the AllList.
In short, XML->internal for CPP would be nice. But because CPP has to work with
both Linux/Unix and Windows platforms, and because native XML infrastructure is
so radically different between the two, we've never had the time to work
through all the concerns.
Hope this helps.
Regards,
-gww
________________________________
From: Klaus Holst Jacobsen [mailto:[email protected]]
Sent: Thursday, December 10, 2009 12:00 AM
To: LLRP Toolkit Development List
Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti
binary f ormat
Hey
Thanks for all the very quick responses.
Sounds like a good idea with perl and binary representation.
I have however not yet given up the thought of having cpp encode from xml
directly. On thing that struck me as kind of odd though is the following. Each
CElement has a list of parameters (m_listAllSubParameters), but at the same
time e.g. the CADD_ROSPEC message has a member variable (m_pROSpec) holding the
contained ROSpec parameter. But why not simply hold the ROSpec parameter of
CADD_ROSPEC in the Celement::m_listAllSubParameters instead of having a
dedicated member variable. This would make it so much easier to parse from XML
to objects without having to know the identity of the object you're parsing
right now in order to use special set methods.
Or said in other words:
What would happen if I added a CROSpec parameter to a CADD_ROSPEC message using
Celement::addSubParameterToAllList(...) instead of CAD_ROSPEC::setROSpec(...)
and then parsed that to binary and sent it to a reader?
//Klaus
-----Original Message-----
From: John R. Hogerhuis [mailto:[email protected]]
Sent: 10. december 2009 01:10
To: LLRP Toolkit Development List
Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti
binary f ormat
On Wed, Dec 9, 2009 at 3:53 PM, Paul Dietrich <[email protected]> wrote:
> As an alternate to Johns idea, it may be possible to store your
> configurations in their binary format.
>
Excellent idea... as an extension of that concept, if you need to edit LTK-XML
interactively, LTK-Perl script could be used from the command line as an
intermediary for converting to/from binary format.
So if you edit LTK-XML with a text editor, you can compile it to binary with
Perl. Then LTK-CPP will allow you to manipulate the binary form. Similarly you
can take binary, use Perl to convert to XML, then edit it.
-- John.
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
llrp-toolkit-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
