No, Decode As is currently quite limited (hardcoded) in what you can change dissection to. But I'm guessing ethernet, IP, TCP/UDP (which are all supported) cover a large majority of users.
There can be multiple factors to consider and that's why (I'm guessing) it's as complex as it is (Haven't looked at the gory details behind the engine). For ethernet and IP, yes just child dissectors would do. But for TCP/UDP you have the option to decode in one or both directions of the "stream". I assume the other protocol (as well as "taps") setups have "options" as well.
Currently my goal is to just make the existing protocols supported through Decode As work in a more generic way to reduce GUI footprint, but I think you're right that just checking for registered child dissectors would be the ultimate goal.
Still curious as to the opinion of being allowed to use capture_file* in dissectors.
-----Original Message-----
From: Evan Huus <eapache@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Wed, Nov 13, 2013 12:19 pm
Subject: Re: [Wireshark-dev] capture_file* in dissector code
I wasn't aware that Decode As was this complicated at all - I thought
it simply referenced the various dissector table registrations to
generate the relevant lists? Should it not simply be checking if there
are registered child dissectors?
