> On Aug 4, 2014, at 17:21, Roland Knall <[email protected]> wrote: > > >> Am 04.08.2014 um 23:16 schrieb Evan Huus <[email protected]>: >> >> >> >>> On Aug 4, 2014, at 17:11, Roland Knall <[email protected]> wrote: >>> >>> >>> >>> >>>> On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus <[email protected]> wrote: >>>> Right now you can't filter on field combinations that must appear >>>> "together" in one of those application frames: if fieldA appears in frame >>>> 1, and fieldB appears in frame 2, then that packet will match "fieldA && >>>> fieldB" even if they never appear "together" in the way a normal human >>>> would intend. Being able to label each of those frames as a separate >>>> "record" would solve this problem. >>>> >>> >>> One thing to look out for here is the fact, that this may change behavior >>> of the display filters in a way, the end-user may never see coming. We >>> would have to come up with a syntax in wireshark, where we allow either >>> "(fieldA && fieldB)" meaning, record1.fieldA and record2.fieldB or fieldA >>> and fieldB in the same record. The end-user does not necessarily make that >>> distinction. If he simply selects frame fields, he may end up with display >>> filters which do not filter the intended or any packages, but he has no >>> clue why simply because the display filter interprets the syntax in a way >>> the end-user could not foresee. >> >> Yes, I was thinking some additional syntax like wrapping an expression in {} >> or something to indicate it should only match within a single record. >> > > It should be the other way around. The new syntax should emphasize the fact > that it should match in different records, otherwise you are going to break > compatibility with the current usability.
? Right now we match regardless of records - that should continue to be the default so that existing display filters don't break. We should introduce a new syntax for the new feature... Or is that what you are already saying? > >>> On the rest, I see your point. >>> >>> regards, >>> Roland >>> >>> ___________________________________________________________________________ >>> Sent via: Wireshark-dev mailing list <[email protected]> >>> Archives: http://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >>> mailto:[email protected]?subject=unsubscribe >> ___________________________________________________________________________ >> Sent via: Wireshark-dev mailing list <[email protected]> >> Archives: http://www.wireshark.org/lists/wireshark-dev >> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev >> mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
