This is getting complicated. A few points in no particular order:
=== tshark default behaviour ===
We can't make -2 the default for tshark doing live capture, as that
would require us to buffer all output until the capture is finished,
which isn't very helpful. We might want to make it default when
reading from a file, but then the two cases will behave subtly
differently and there's a possibility for people to become confused.
In general, there is *no way* for tshark doing a live capture to
console to fill in things like fragment reassembly and
request/response tracking the way wireshark does, because that would
require it to predict the future (patches welcome!). So we already
have a case where tshark *cannot* behave like wireshark, which is
fundamentally very annoying.
This raises the question of where we want our consistency - do we want
tshark internally consistent by default (in which case we should keep
-2 as an option) or do we want tshark to be as-consistent-as-possible
with wireshark, even if we can't quite achieve all cases (in which
case -2 should be the default except when doing a live capture).
=== architecture ===
I don't see an obvious good reason for tshark and wireshark to share
any more of their processing code than they already do. Wireshark gets
its two-pass behaviour 'for free' because it does one pass when
displaying and one pass when saving. Tshark generally only does either
one or the other in the first place (display or save), and even if it
were to do both, it makes more sense for it to do them together than
in series.
Tangentially: Hadriel, you are correct with respect to the frame list
(I worked on this yesterday in r48030) - I can't speak as much for the
packet list store.
=== filtering ===
I *really* do not like the renumbering of frames that the read filters
currently do (-R in wireshark, -2R in tshark). I find it confusing and
not useful entirely apart from the fact that there is no graceful way
for it to handle reassembly dependencies (see my "frame 1 depends on
frames 1 and 1" example earlier). Does anybody know why it was added
in the first place? It seems to me that it adds very little that was
not already available by using a regular display filter and saving the
results to a new file.
=== proposal ===
- Scrap "-R" and read filters entirely, making the requisite changes
to the GUI so that the file->open filter behaves as Hadriel suggested
(basically just a proxy for the regular display filter field).
- Synchronize on -f for libpcap filters and -d for wireshark filters
- Tshark only does one pass by default in all cases (so it's
internally consistent). Keep -2 for two-pass analysis, but *never*
renumber frames.
- Improve the man page description for -2 to explain more clearly the
benefits and drawbacks. Mention -2 early in the 'description' portion
of the man page so that people looking for that functionality will
find it.
