On Thu, Mar 1, 2018 at 11:22 AM, Graham Bloice <graham.blo...@trihedral.com> wrote:
> > > On 1 March 2018 at 10:18, Roland Knall <rkn...@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-requ...@wireshark.org?subject=unsubscribe
