> Would this problem be smaller if the feature was only operational for
> packets of the same type.
I'm assuming here that by "packets of the same type" you mean "packets
that, at the layer where the protocol-tree item is selected, are of the
same type"; it wouldn't make it any easier to select a given protocol
tree selection at, say, the IP layer to make it work only if the two
packets are both TCP packets, say, and it wouldn't make it easier if the
selection is at the TCP layer if both packets are HTTP packets.
That wouldn't make it easier for lines in the protocol tree not
associated with filterable fields, as per:
> unless the current line has a field associated with
> it, there's no way for Ethereal to know which line in the new packet's
> protocol tree would correspond to the selected line in the old packet.
It also wouldn't make it easier for lines in the protocol tree
associated with a filterable field that occurs more than once in the new
packet, as per:
> if the new packet has exactly one instance of that field, we could
> probably re-select it, but if it has more than one of them, which one
> should it pick?
Furthermore, if the line selected is assciated with a filterable field,
and there's only one instance of that field in both packets' protocol
trees, the problem is trivial - select the one-and-only entry
corresponding to that field in the new packet's protocol tree.
So no, I don't think the problem would be reduced in size at all.
For the "more than one instance" problem, I suspect the best we can do
is select the first instance of that field, if any, in the new packet's
protocol tree; that would do the right thing if there's only one
instance, and if there's more than one instance, "the right thing" is to
infer what the user wanted, and do that, but I suspect that's
impossible.
For the "selected entry doesn't have a field associated with it"
problem, I'm not sure there is a solution short of "well, fix the
dissector to associate a field with it" - one could perhaps take the
text from the entry in the old packet, look for a colon, treat
everything from the beginning of the text up to the colon as the name of
the field, and search the new packet's protocol tree for entries that
have no filterable field associated with them and whose text contains
the same string, followed by a colon, at the beginning, and select the
first of those, if any are found.
