Re: RFC: Internally Generated "Records"

[Evan Huus <eapache () gmail com>]

> 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
> > ___________________________________________________________________________
> > 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
___________________________________________________________________________
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