On Tue, Jul 11, 2017 at 8:07 AM, m...@verizon.net <mlan...@verizon.net> wrote: > I was concerned about the c++ issue, which helped motivate the question. > > Only one object file requires c++. In fact, I'm still compiling my modified > tshark in C. The required function in the c++ object file is callable from > C. > > Pascal, do you think that this is still to much of a barrier?
I would say that it is a big barrier. You are also requiring us to link in the C++ runtime and protobufs and all the libraries it wants possibly including boost etc. > Sent from my iPhone > > On Jul 11, 2017, at 10:47 AM, Pascal Quantin <pascal.quan...@gmail.com> > wrote: > > Hi Mark, > > 2017-07-11 16:07 GMT+02:00 m...@verizon.net <mlan...@verizon.net>: >> >> Thanks Roland! >> >> I guess I'm asking if it'd be value added for me to submit my protobuf >> solution as an addition to current Wireshark dev branch. I've already >> written the code. I'd just have to figure out how to incorporate it into the >> Wireshark build process. It's written in c++ and requires pthread and >> protobuf libs be installed. > > > This is a first issue as all Wireshark code (except the Qt GUI) is written > in C and this is not something we discussed changing so far. > >> >> Happy to do it but would be good to know beforehand if it'd be compatible >> with Wireshark design ethos and if the community would see value in it. >> >> Sent from my iPhone >> >> On Jul 11, 2017, at 9:00 AM, Roland Knall <rkn...@gmail.com> wrote: >> >> Did you take a look at tshark's -T parameter? "tshark -T jsonraw" for >> instance, delivers full dissection in Json format. What would be needed is >> only to shove that into a pipe to capture from some other place. >> >> Cheers >> Roland >> >> On Tue, Jul 11, 2017 at 2:48 PM, Mark Landriscina <mlan...@verizon.net> >> wrote: >>> >>> >>> Apologies in advance if this question is a bit long-ish. >>> >>> I've been wondering why Wireshark/tshark doesn't offer the option to >>> export full packet dissection data via named pipe (serialized binary data). >>> Is this due to design philosophy, lack of offers to write the code, or some >>> other reason? Of course, packet dissection data can be written out to stdout >>> or a file in xml format. Perhaps this meets most needs? >>> >>> Reason for the question is that I needed a dissection data export option >>> that was more efficient than xml. My solution was to modify tshark so it can >>> leverage Google Protocol Buffers to export packet dissection data as >>> serialized binary data. Serialized dissection data is written out to a named >>> pipe. Protobuf dissect tree creation, serialization, export code is all >>> written in C++ and takes advantage of all the optimization work Google has >>> put into its Protobuf library. The client/read side of the pipe can be >>> written in any language supported by the Protobuf library. I wrote mine in >>> Python. The client reads and parses the serialized dissection data (again) >>> using Google Protobuf lib recreating dissection tree data on client side. >>> >>> Would it be advantageous to incorporate the above Protobuf approach into >>> the Wireshark project or would the community consider it unnecessary or >>> perhaps undesirable? >>> >>> If you're curious about implementation, you can see my project at the >>> following location: https://gitlab.com/MLandriscina/protoShark.git. This is >>> the first time that I've used Protobuf, so I wouldn't be surprised to >>> discover that better implementations are possible. >>> >>> >>> >>> ___________________________________________________________________________ >>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >>> Archives: https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>> >>> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe >> >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe >> >> >> >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >> Archives: https://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >> >> mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
