Comment # 39
on bug 9607
from Evan Huus
My feeling is still about the same as my comment #13 on this bug - I think the
eventual job of "filetap" will just be to load the file into a TVB and return
it, which isn't sufficiently complicated to warrant a whole library.
We need to solve the dissectors-controlling-the-summary-pane problem anyways
(as Guy suggests, for TCP-based protocols and others) so "record-based"
fileshark will naturally fall out of that without the need to spread dissection
code into two places.
My preferred plan of attack would be:
1. Put aside the existing tfshark and and libfiletap work, and write a simple
"tfshark.c" that fread()s a file into memory and passes it as a single "frame"
(tvb) to epan. This should be a relatively small amount of code, probably only
a couple hundred lines, and gives us just enough to actually be able to dissect
files and get output.
2. Write a file-file.c (like packet-frame.c) which adds the file-name as a
[generated] field and contains the top-level subdissector table for file
formats. This lets us remove all the non-packet file formats from wiretap.
3. Write a file-backed TVB implementation, which can just plug in (replacing
the fread() call from 1.) with minimal fuss. This isn't required, it's just an
optimization for large files to avoid reading them into memory all at once.
4. Figure out the magic-summary-tree-v2.0 and how it's going to work. I think
this is probably the most challenging step, but it's not really a
Fileshark-specific problem, so we shouldn't discuss it strictly in the context
of Fileshark. Once this is done, file dissectors can implement their records in
terms of this, and there's no other actual architectural work to do.
Thoughts?
You are receiving this mail because:
- You are watching all bug changes.
