On 1 March 2018 at 10:27, Roland Knall <rkn...@gmail.com> wrote: > > > 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? > > 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-requ...@wireshark.org?subject=unsubscribe
