Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Guy Harris
On Jul 11, 2017, at 8:17 AM, Anders Broman wrote: >> and requires pthread and protobuf libs be installed. > > Is this portable to MAC and Windows? Pthreads are part of any reasonably modern UN*X, so they're available in macOS and *BSD and Solaris and HP-UX and AIX, as well as at least some dea

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Richard Sharpe
On Tue, Jul 11, 2017 at 11:34 AM, Mark Landriscina wrote: > Google indicates that Protocol Buffers is portable across MAC, Windows, > Linux though I've only used it in a Linux build env. My code is certainly > platform agnostic. The business case for using Protocol Buffers instead of > XML or JSON

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Mark Landriscina
Google indicates that Protocol Buffers is portable across MAC, Windows, Linux though I've only used it in a Linux build env. My code is certainly platform agnostic. The business case for using Protocol Buffers instead of XML or JSON is performance wrt to data serialization and serialized data pa

Re: [Wireshark-dev] Should I add new commits to address review comments?

2017-07-11 Thread Pascal Quantin
Hi Richard, 2017-07-11 18:10 GMT+02:00 Richard Sharpe : > Hi folks, > > Last time I made a change I created a new commit based on review > comments and then squashed the two commits, but that caused issues. > > Is it better to simply submit the new commit or do I need to ensure I > keep the origi

Re: [Wireshark-dev] Should I add new commits to address review comments?

2017-07-11 Thread Graham Bloice
On 11 July 2017 at 17:10, Richard Sharpe wrote: > Hi folks, > > Last time I made a change I created a new commit based on review > comments and then squashed the two commits, but that caused issues. > > Is it better to simply submit the new commit or do I need to ensure I > keep the original chan

[Wireshark-dev] Should I add new commits to address review comments?

2017-07-11 Thread Richard Sharpe
Hi folks, Last time I made a change I created a new commit based on review comments and then squashed the two commits, but that caused issues. Is it better to simply submit the new commit or do I need to ensure I keep the original change-id in the commit? -- Regards, Richard Sharpe (何以解憂?唯有杜康。-

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Anders Broman
> and requires pthread and protobuf libs be installed. Is this portable to MAC and Windows? Regards Anders From: Wireshark-dev [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Pascal Quantin Sent: den 11 juli 2017 17:13 To: Developer support list for Wireshark Subject: Re: [Wireshark-de

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Richard Sharpe
On Tue, Jul 11, 2017 at 8:07 AM, m...@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. > >

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Pascal Quantin
2017-07-11 17:07 GMT+02:00 m...@verizon.net : > 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

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread m...@verizon.net
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? Sen

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Pascal Quantin
Hi Mark, 2017-07-11 16:07 GMT+02:00 m...@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 > t

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Richard Sharpe
On Tue, Jul 11, 2017 at 7:07 AM, m...@verizon.net wrote: > 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 th

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread m...@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 pth

Re: [Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Roland Knall
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 wrote: > > Apologies

[Wireshark-dev] Using Google Protobuf to Export Full Packet Dissection Data via Named Pipe

2017-07-11 Thread Mark Landriscina
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