2017-04-05 16:13 GMT+02:00 Alexis La Goutte <[email protected]>:
> Hi, > > There is some dissector using XML ? (diameter...) > May be see to convert (or using actual XML code) > If libxml2 is integrated as an optional dependency, then we should not convert dissectors (like diameter) and keep our own lex based parser (otherwise you would have a functionality loss when you build without it). If libxml2 becomes a mandatory requirement, this could be revisited. > > Cheers > > On Wed, Apr 5, 2017 at 3:48 PM, Pascal Quantin <[email protected]> > wrote: > >> Hi Ahmad and Graham, >> >> 2017-04-05 15:38 GMT+02:00 Graham Bloice <[email protected]>: >> >>> >>> >>> On 5 April 2017 at 14:11, Ahmad Fatoum <[email protected]> wrote: >>> >>>> Hello everyone, >>>> >>>> I was advised on Gerrit to post this issue here as to garner wider >>>> input. >>>> >>>> This concerns proposed Change-Id I13c0a2f408fb5c21bad7ab3d7971e >>>> 0fa8ed7d783 [1] intending to add libxml2 as optional dependency to >>>> Wireshark. >>>> >>>> I am currently preparing to submit upstream, changes I did to the EPL >>>> v2 dissector (packet-epl.c). >>>> >>>> A significant change is the ability to optionally read in user-supplied >>>> XML device descriptions and to extract type/description/mapping information >>>> for aiding the dissection. See this previous submission of mine to the >>>> mailing list: https://www.wireshark.org/lists/wireshark-dev/201701/m >>>> sg00154.html >>>> >>>> >>>> Seeing as there also has been interest for libxml2 support in >>>> dissectors in the past: >>>> >>>> https://www.wireshark.org/lists/wireshark-dev/201005/msg00108.html >>>> >>>> https://ask.wireshark.org/questions/36063/using-libxml2-in-m >>>> y-own-dissector >>>> >>>> >>>> I think, it would be a good idea to have this as optional dependency as >>>> Glib's GMarkup may be inadequate or inconvenient for parsing actual XML. >>>> >>>> >>>> Looking forward to your feedback. >>>> >>>> Best regards, >>>> Ahmad Fatoum >>>> >>>> [1] https://code.wireshark.org/review/#/c/20912/ >>>> >>> Thanks for the post, >>> >>> 1. Where will the Windows binaries come from and are these supported >>> long term? The libXml2 downloads page indicates another site provides >>> Windows binaries [1]. The binaries at that site in the 64 bit directory >>> seem to be the most recent and are labelled as libXml2-2.9.3 [2]. The >>> current release of libXml2 is 2.9.4 which has a number of security fixes >>> among other bug fixes and enhancements [3] so it would appear that the >>> Windows binaries are not being maintained. >>> >> >> I suggest to use the binaries provided by openSUSE: they provide win32 >> and win64 variants for libxml2 2.9.0 and we are already using their >> packages for several third party libraries. If it is really required to >> take the latest version, I can probbly give it a try (I already did this in >> the past to package a newer version than the one from openSUSE). >> >> >>> 2. According to the diagram at [1], libXml2 depends on iconv and zlib. >>> We currently build our own zlib, will that be suitable for the libXml2 >>> dependency? What will be the source of the iconv binary (iconv-1.14 is >>> available in the same download area as libXml2 [2])? >>> >> >> Same thing: we can use the ones provided by openSUSE (we already have >> those dependencies for other packages). >> >> >>> >>> 3. The readme.txt in the download area ([2]) has some "interesting" text: >>> >>> These are experimental 64bit binaries. For completeness, 32bit binaries >>> built using the same method are also included. >>> >>> The libraries in these packages are made using GCC (MinGW) toolchain. It is >>> presently not possible to use these libraries with any recent version of the >>> Microsoft Visual C compiler because of conflicting C-runtimes. To help you >>> resist the temptation, the import libraries (.LIB) are not provided at all. >>> If you need these libraries in an environment which mandates the use of the >>> Microsoft toolchain, you will have to build them from source yourself. >>> >>> and inspection of the download shows this is true, so it appears that >>> we'll need to rebuild to obtain the import .lib file. >>> >> >> As part of the process of integrating openSUSE libraries, we are >> generating the .lib file and adding it in the package we upload on our >> server, so it should be OK. >> >> >>> 4. Microsoft have a Visual Studio porting effort underway called vcpkg >>> [4], that does include libXml2, but unfortunately is only for VS2015 or >>> later. If we move to VS2015 for main releases (post 2.4 release) then this >>> may be a viable source for libXml2 and other packages we use. It might be >>> possible to use this to build VS2013 libXml2. >>> >>> 5. Are there any manufacturers or tools that produce XML device >>> description files for the EPL dissector such that choosing XML as the input >>> format is the most sensible choice, or would another format be just as >>> applicable? >>> >> >> I agree XML can be painful, so this is a good question ;) >> >> >>> >>> >>> [1]: https://www.zlatkovic.com/libxml.en.html >>> [2]: ftp://ftp.zlatkovic.com/libxml/64bit/ >>> [3]: http://xmlsoft.org/news.html >>> [4]: https://github.com/Microsoft/vcpkg >>> >>> -- >>> Graham Bloice >>> >>> >>> ____________________________________________________________ >>> _______________ >>> Sent via: Wireshark-dev mailing list <[email protected]> >>> Archives: https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>> mailto:[email protected]?subject=unsubscr >>> ibe >>> >> >> >> ____________________________________________________________ >> _______________ >> Sent via: Wireshark-dev mailing list <[email protected]> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject=unsubscr >> ibe >> > > > ____________________________________________________________ > _______________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject= > unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
