Re: Dissector - plugin or built-in

[Roland Knall <rknall () gmail com>]

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?

cheers
Roland

___________________________________________________________________________
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