On Fri, Jan 21, 2000 at 04:27:10PM -0600, Nathan Neulinger wrote:
>
>
> This raises an issue - do we have any policy on when stuff should be a
> plugin?
No policy. But the plugin capability was added when Olivier needed to
decode some proprietary protocols inside his company. He could not release
the source code to their dissectors to the public. By providing the plugin
capability, he can use an unpatched Ethereal inside his company and provide
plugins for their protocols.
I chose to make the gryphon decoder a plugin because it's audience is
extremely limited, and it was given to us at just the right time, when we were
ready to release Ethereal with plugin support for the first time. It makes
a good example (I hope! :-) of how to write plugins.
So, for any protocol a company does not want to document publically,
plugins are the way to go (much like non-GPL device drivers that are loaded
by the Linux kernel). The only dissectors that we'll include in the
Ethereal source as plugins are those that are intended for an
extremely limited audience (versus only a "very limited" audience :-)
One could argue that since you have no, to pick on one dissector, token-ring
on your network, for example, that we should make token-ring either a plugin or
a configure-time option. You might want SMB or NFS to be plugins too, since
they are large dissectors. We haven't discussed that possibility at all.
I rather like having all the dissectors configured to run by default, since
you never know *what* you'll see on your network.
--gilbert