[bugzilla-daemon@xxxxxxxxxxxxx]

Comment # 14 on bug 9607 from Michael Mann

(In reply to comment #13)
> I still feel like I'm not doing a great job explaining myself :/ I shall try
> again:

I've certainly followed it all and I think it's all things that need to be
said/discussed (just not sure if it should be in this bug or -dev).  Comment
#13 is a nice summary of comment #12 and overall I still prefer (and have been
working towards) the second approach.  However I feel I've reached the point
where "disruption" is about to occur in order to go farther with it.

> Wiretap can be viewed as a function that takes a raw file as input,
> and outputs some metadata and packet records.

Yes, that was my goal with Filetap - to take a raw file and turn it into an
array of records and metadata (that I would usually see as a "header")

> Epan can be viewed as a
> function that takes those metadata and packet records as input, and outputs
> the dissection of those records.

Then the output of Filetap should able to be cleanly passed to Epan without
modification

> Wireshark chains those two libs together
> to produce a function taking raw files as input, and outputting dissections
> of the packets in those files.

> Fileshark, ideally, takes raw files and
> produces the dissection of the files themselves. I think the simplest way to
> accomplish this is to generate dummy metadata and a dummy record, pass those
> to epan and let it do the work. I don't think this process is complicated
> enough to warrant it's own library - it's just a few memzeroed structs and
> one file-backed TVB.

I agree it doesn't really need it's own library, but I created one to not
disrupt wiretap in its current state (because functionality was different
enough).  I don't like the idea of that much "dummy data".  "Long term" I
thought both could be merged, but I didn't want to take that time now and hold
up the fileshark idea.

Since Wireshark's architecture is more "record based" (from epan all the way
through the GUI and how information is displayed), I was intentionally trying
to gear the filetap/fileshark design towards record based file formats.  The
"file dissectors" that currently exist and want to be committed all fall in
that category.  If someone wanted a non-record based file to part of fileshark,
I would want them to "hack" something to treat the entire file as a single
record, but I'm hoping that's the exception, not the rule.  That's why I didn't
want to start with presenting the whole file as a single tvb. 

> On that method, Fileshark adapts to epan's API. We
> could, alternatively, do a great deal of work to make epan's API more
> generic (presumably by splitting it into a generic part, a packet part, and
> a file part). In this case fileshark would be able to pass the raw file
> directly to the "file-specific epan" API, and would also not need an
> intermediate library.

I thought the current "file dissectors" have proven that epan's API doesn't
need to modified as long as file has a record based architecture.  And that's
all I want Fileshark to be at the moment.

---

      You are receiving this mail because:

• You are watching all bug changes.