ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Ethereal-dev: Re: [Ethereal-dev] 0.10.10 next week?

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Lars Roland <lars.roland@xxxxxxx>
Date: Sat, 05 Mar 2005 17:00:44 +0100
Jaap Keuter schrieb:
On Sun, 6 Mar 2005, ronnie sahlberg wrote:


On Sat, 5 Mar 2005 14:15:45 +0100 (CET), Jaap Keuter
<jaap.keuter@xxxxxxxxx> wrote:

On Sat, 5 Mar 2005, ronnie sahlberg wrote:


do we need plugin support?   it is a serious question.

Serious answer: Yes

[rant deleted]

end of rant.

I think we shoudn't underestimate the use of the plugin model for
not-for-public dissectors and quick dissector development.
Private dissectors may be restricted from distribution (proprietary
protocols, linked to NDA's). So it may be unacceptable to build them into
installers, which may leak more easily, since they look like stock
Ethereal installers. The model is that stock installers are distributed
around, while the private dissectors are added to a lab installation only.
Dissector development based on the plugin model makes it:

I understand fully well that some protocol dissectors can not/should
not go into ethereal for various reasons.
I frequently use several such protocols and dissectors myself.

The question was not regarding whether ethereal should allow/disallow
such dissectors, far from it.
The question was based on my personal observation that the plugin
interface has currently failed to make this possible.

In my experience, many maintainers of out-of-tree protocols seem to
prefer to just make a special build about once a year or so with the


Once a year?!? That's like prehistoric. Oke, we're using a lot of the VoIP
related features, which improve every release, so we upgrade just about
every release. We've hit only a few bump in the road for the plugins we
use.


out-of-tree dissector built in as a normal dissector,   then the full
version of ethereal with this special dissector built in is
distributed to the lab.


A full version is what we try to avoid. A stock version for everyone,
special dissectors in plugins for the lab.


If my observations from my exposure to this limited subset of all
out-of-tree dissectors that exists are invalid or not the norm, then
ok.
Othervise, if my experiences are the norm, then  why bother with a
plugin interface if the out-of-tree dissector maintainers arent
bothering with it either?

Are the out-of-tree maintainers using the plugin api?
The ones i use are not using the plugin api.


The ones I use (and maintain) do use the plugin API.

So, it all comes down to a majority vote then. But how are we gonna get
it? This list is not the way to poll, the wiki maybe?

Nothing to vote here. The new plguin api scheme is quite easy to maintain. We can afford to keep it easily. Maintaining the plugins themselves is something different. On windows you'll have to build your plugins again, when libethereal.lib has changed, which happens quite frequently and might be very annoying. On a UNIXish machine, the plugins do not depend on any specific api, they depend only on the imported and used functions only. As Richard Urwin noticed, plugins may work for a long time this way.

Regards,
Lars