Ahhh great. One question though.
When my derived XMLDecoderStream gets a callback e.g. get_u8(const CFieldDescriptor * pFieldDesc) and the message has multiple fields of the same type. How can the decoder know whether it's the one or the other particular instance of that field type being decoded. E.g. ADD_ROSPEC can contain multiple RFTransmitter parameters and thus multiple TransmitPower fields. When the my new XMLDecoderStream gets a callback for decoding a TransmitPower field how can it know whether its one or the other actual field that is being decoded right now? //Klaus _____ From: Gordon Waidhofer [mailto:[email protected]] Sent: 14. december 2009 09:10 To: LLRP Toolkit Development List Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti binary format Please take a look at the way a frame is decoded. A Decoder object guides the decode. It passes a DecoderStream (something like that) to a parameter's member function. That member function asks for each field in order and provides name and type information. An XML decoder should be able to leverage the existing approach. Determine the kind of parameter, instantiate one, ask it to pull out the fields which it does with callbacks, then whatever is left is subparameters. Process the subparameters placing them on the AllList. Once done, ask the original parameters assimilate function to put them in the right place. Hope this helps. Regards, -gww _____ From: Klaus Holst Jacobsen [mailto:[email protected]] Sent: Sunday, December 13, 2009 11:56 PM To: LLRP Toolkit Development List Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti binary format Yes that "assimilate" function was exactly what I was looking for. With this mechanism it is possible to create proper CElement derived objects without knowing the exact type at time of creation. But now I stumbled on the next challenge: Fields. Is there a similar mechanism to add fields to parameters anonymously and then "assimilate" those fields afterwards? Or will I have to use the specific get/set methods in the derived CParameter classes? //Klaus _____ From: Gordon Waidhofer [mailto:[email protected]] Sent: 11. december 2009 22:48 To: LLRP Toolkit Development List Subject: Re: [ltk-d] Parsing XML representation of e.g. ADD_ROSPEC message ti binary f ormat 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] <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 <http://p.sf.net/sfu/google-dev2dev> _______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel <https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel>
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ llrp-toolkit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/llrp-toolkit-devel
