Hmm, I don't know what I'm thinking of "file dissectors" as being analogous to wiretap modules. I should have thought of them as dissectors instead. My fault.
As long as we have plugins with a good API, then that's good. In fact, we should have a better plugin API than what we have now. I am thinking specifically of custom file formats that I would want to write "file dissectors" for (for some proprietary file formats at my job). Thanks, Gilbert On Thu, Jun 20, 2013 at 3:57 PM, Evan Huus <eapa...@gmail.com> wrote: > On Thu, Jun 20, 2013 at 2:39 PM, Gilbert Ramirez <g...@alumni.rice.edu> > wrote: > > I've written some tools to read various file formats, and what I have > > learned from this is that it's really most useful to create: > > > > 1. a generic library for reading a file format. > > 2. an application dissector (i.e, a FileShark dissector) for using the > > generic library, and providing the API that the application (FileShark) > > wnats. > > 3. And on top of that, FileShark itself. > > > > This is good so that other programs besides FileShark can make use of the > > generic libraries. > > I think this is the wrong way to approach the problem. To draw a > parallel, there's a reason we don't just link a normal TCP stack into > Wireshark. The goal is to be able to display the raw structure of the > file/packets, which is sometimes quite different from the values that > an application reading the file/packets is going to care about. > > > This is different from how we did wiretap, in which the logic for > dissecting > > a packet capture is embedded directly in the wiretap module. If another > > application wanted to decode packet captures, it would have to link > against > > wiretap, and use its APIs. > > Wiretap is a library for reading packet file formats, which is > basically step 1 of your proposal. I'm not entirely clear on what in > your proposal is different, or why it makes sense to do this. > > > This would mean we might spawn some new projects that read the file > formats, > > and those would be separate from FileShark itself. But, that's more > > generally useful. > > If we're going to be decoding a file in Fileshark, there's almost > certainly already a library to read/write it for applications, as > otherwise there would be no files for us to decode. > > > Taking this a step further, maybe it's time to "harden" the APIs of the > > various modules of Wireshark, and also break apart Wireshark. wiretap > could > > be removed entirely out of the Wireshark source base, and put into its > own > > SCM repo and released independently. > > I would be very happy to make proper libraries out of wiretap, > dfilter, epan, etc (and I designed wmem with this in mind). I suspect > splitting them out into multiple repositories is just making work at > this point, but if there's interest once they're usable stand-alone > then it might make sense to reconsider. > > Evan > > > Gilbert > > > > > > > > > > > > On Thu, Jun 20, 2013 at 2:15 PM, Guy Harris <g...@alum.mit.edu> wrote: > >> > >> > >> On Jun 20, 2013, at 11:54 AM, Evan Huus <eapa...@gmail.com> wrote: > >> > >> > 3. Create a separate application called Fileshark that doesn't use > >> > wiretap and links only against libfiledissectors. When dissecting > >> > files directly, wiretap simply gets in the way. Additionally, people > >> > have pointed out several possible UI changes that make sense for files > >> > but not for packets. While hopefully Fileshark and Wireshark will be > >> > able to share much of their code, there are still places where they > >> > will diverge and we want to be able to do that cleanly. > >> > >> Yes. For example, in Fileshark, you either: > >> > >> 1) might want to show, in a summary pane, multiple items for > >> multiple sections/records/etc. of a file > >> > >> or > >> > >> 2) show only one pane, a detail pane, so that with everything > >> closed up, you have a list of sections/records/etc.. > >> > >> > Some of the consequences of this: > >> > - Wireshark proper will not open non-capture files directly. It will > >> > parse files it sees over transport protocols, but to parse an on-disk > >> > file directly will require opening it in Fileshark. > >> > >> Note, BTW, that you might well want to have file dissectors for various > >> forms of capture files that Wireshark can read; if you open those files > in > >> Wireshark, they'd show you the packets (and perhaps other records), but > if > >> you open them in Fileshark, they'd show you the file header (if there is > >> one) and the file records (including the raw contents of record headers, > >> etc.) - that might be a useful tool for Wireshark developers > >> reverse-engineering features of not-publicly-documented file formats. > >> > >> > ___________________________________________________________________________ > >> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > >> Archives: http://www.wireshark.org/lists/wireshark-dev > >> Unsubscribe: https://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: http://www.wireshark.org/lists/wireshark-dev > > Unsubscribe: https://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: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://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: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
