Ethereal-dev: Re: [ethereal-dev] enhancement idea...
> On the right click idea, some other useful right click operations on the
> packet list:
> follow stream
BTW, at some point it might be nice to have "Follow Stream" do more than
*just* follow TCP streams; other transport-layer connection-oriented
protocols could also implement something along those lines, as could
protocols above the transport layer - for example:
TFTP conversations involve one packet going from host A port a
to host B's TFTP port, a reply coming back from port b on host B
to port a on host A, and all subsequent traffic going between
A:a and B:b;
an ONC RPC conversation might consists of all request/reply
pairs for the RPC service in question between the two hosts in
question;
an NFS conversation could be the ONC RPC NFS conversation *plus*
the mount daemon, lock manager, status monitor, and Sun ACL
protocol;
an HTTP conversation could involve all HTTP traffic between the
given client host and the given server (and perhaps, if you're
feeling sufficiently perverse, if the stuff coming back from the
server is "text/html", scan it for URLs and include fetches of
those URLs from other servers, e.g. banner ads...);
etc., and one could imagine conversations at the network layer (e.g.,
"show me all the IP traffic between hosts A and B").
> ? move column left
> ? move column right (wish that clist did this by dragging the column
> titles)
Network Monitor does that.
At some point, we might want to think about doing our own CList
replacement, with:
drag-and-drop column moving;
ability to add and delete columns on the fly;
perhaps "lazy evaluation", wherein a given row has a function
and argument associated with it and, when that row has to be
displayed, the given function is called with the given argument
and some pointer that lets it fill in the columns - that might
let us do relatively little work to construct the summary list,
and only dissect packets if the column is to be displayed (I
have the suspicion that's how Network Monitor does it, as it
seems to read capture files very fast, although filtering and
printing, both of which involve dissecting packets, are slower).
If it's sufficiently general, it might be worth contributing back to
GTK+.
