Re: Dissector - plugin or built-in

[Graham Bloice <graham.bloice () trihedral com>]

On 1 March 2018 at 10:27, Roland Knall <rknall () gmail com> wrote:

> On Thu, Mar 1, 2018 at 11:22 AM, Graham Bloice <
> graham.bloice () trihedral com> wrote:
>
> > On 1 March 2018 at 10:18, Roland Knall <rknall () gmail com> wrote:
> >
> > > We do not have any other dissector within the code, which dissects
> > > blocktypes. Therefore I would not be so sure, that it will get rejected (in
> > > my book it definitely should not).
> > >
> > > But it most likely will get rejected as a plugin.
> > >
> > > Main reasons for built-in:
> > >
> > > - Easier to maintain
> > > - Best-practice approach
> > > - Would name it something like blocktype_trb.c or similar to distinguish
> > > from protocol-only dissectors
> >
> > Should we have a separate spot in the source tree for block type
> > dissectors?  I'm not sure if we will ever have lots, but should we keep
> > epan/dissectors for "protocol" dissectors.
>
>
> Yeah, I was thinking along the same lines. like epan/blocktypes in
> comparison to epan/dissectors
>
> But we already have file-xxx dissectors in there. It would also make sense
> to have a epan/dissectors/packet, epan/dissectors/file,
> epan/dissectors/blocktype structure.
>
> What do you think?
Probably just my OCD tendencies kicking in, is there any benefit for devs
to doing so?


> cheers
> Roland



-- 
Graham Bloice

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe