Re: RFC: Internally Generated "Records"

[Roland Knall <rknall () gmail com>]

Yes, that it what I was saying.

Cool, you can look forward to the openSAFETY patch, the minute the change
hit the official repo ;-)

regards,
Roland


On Mon, Aug 4, 2014 at 11:51 PM, Evan Huus <eapache () gmail com> wrote:

> On Aug 4, 2014, at 17:21, Roland Knall <rknall () gmail com> wrote:
>
>
> Am 04.08.2014 um 23:16 schrieb Evan Huus <eapache () gmail com>:
>
>
>
> On Aug 4, 2014, at 17:11, Roland Knall <rknall () gmail com> wrote:
>
>
>
>
> On Mon, Aug 4, 2014 at 10:40 PM, Evan Huus <eapache () gmail com> 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 <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> <wireshark-dev-request () wireshark org?subject=unsubscribe>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> <wireshark-dev-request () wireshark org?subject=unsubscribe>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
> <wireshark-dev-request () wireshark org?subject=unsubscribe>
>
>
> ___________________________________________________________________________
> Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>              mailto:wireshark-dev-request () wireshark org
> ?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe