Thank you for the tip. However my problem is not so much about being
able to do the job of parsing the XML. It is a more a
philosophical/API question. Is it ok to dissect something in a way
that leaves lots of bytes unexplained? Also, is it possible to show a
more general and a less general dessections of the same data?
I am looking at OpenDHT client interface here. The protocol parses as
XML, but it also parses as XML-RPC, and as an OpenDHT function call.
If I take it to the level of showing information relevant for an
OpenDHT function call I will have to ignore most of the XML because it
is just meta data that tells me where the payload is, and showing that
to the user makes the result harder to understand.
It is also a quesiton of user interface design. If I can parse
something as an OpenDHT function call and show the meaningful results
for that, should we still show the parsed XML for someone who is
interested for the validity of the xml, or wants to look it up for
features that are not part of the default OpenDHT protocol.
Is it ok to dissect a dictionary and only explain the keys you know
about, or do I need to stop dissecting, if I suddenly find out there
is one key that I do not recognize because it is part of some obscure
extension?
On Tue, Feb 15, 2011 at 6:54 PM, David Young <dyoung@xxxxxxxxx> wrote:
> On Tue, Feb 15, 2011 at 03:05:47PM +0200, Toni Ruottu wrote:
>> I am using Wireshark to analyse services that use XML-RPC calls to
>> communicate. Currently the protocol gets dissected as XML which is
>> fine because it is XML. However the result has lots of bloat that
>> makes it hard for me to analyse the protocol built on top of XML-RPC.
>> Can I somehow write a dissector (?) that analyses only the interesting
>> parts of the protocol, and shows its results "on top" of the more
>> generix XML-RPC dissection, as an alternative way of interpreting the
>> same data. Note that being able to add detail into the atomic parts of
>> dissected XML-RPC does not help, as it is the verboseness of XML-RPC
>> that gets in the way.
>
> I mentored a Google Summer of Code student in 2009 who
> produced stream-oriented XML filter/transform tools,
> <http://netbsd-soc.sourceforge.net/projects/xmltools/>. Maybe the tools
> or the corresponding C library will help.
>
> Dave
>
> --
> David Young OJC Technologies
> dyoung@xxxxxxxxxxx Urbana, IL * (217) 344-0444 x24
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>
