[Guy Harris <guy@xxxxxxxxxxxx>]

Wyer, Andrew wrote:
> I've been using Ethereal / Wireshark for a few years now, but recently 
> needed to add a custom protocol. In learning about developing for this 
> app, it seems that Ethereal plugins are not based on an API and require 
> the full source to be around to compile since the DLL is forced to call 
> core functions to register itself (and various scripts need to scan the 
> code). Is this correct?

Partially.  I wouldn't refer to, for example, register_dissector() or 
dissector_add() as "core functions" in the sense of being different 
from, for example, the proto_tree_add_... functions; when we have a 
published API, the current functions for registering dissectors (or 
something similar) would be part of it.

The scripts would also be part of an installed "developer's kit", along 
with other scripts (such as the scripts to generate dissectors from 
ASN.1 specifications).

I.e., there are really two separate problems:

	1) the API for dissectors isn't yet stable - which means that 
dissectors might have to be changed and recompiled from release to release;

	2) there's no SDK for Ethereal plugins - which means you need the full 
source to build plugins.

> Why not setup an API? If the plugin's gateway functions are passed the 
> information they need, and allowed to return data which is used to 
> register the dissector it would allow plugins to be compiled without the 
> main source, and it would also prevent plugins from breaking with each 
> release.

The problem isn't solely with the dissector registration mechanism - 
that hasn't changed recently, so I don't think it's broken dissectors 
recently.  Other changes to the routines called by dissectors would also 
break plugins.  I don't know what the most recent change is that has 
broken plugins (note that we change the name of the plugin directory 
from release to release regardless of whether plugins would work or not, 
as we currently have no way to automatically check function signatures 
to see whether plugins would be broken).

> I've seen some commented code blocks talk about this 
> (standardized entry functions) and the roadmap says "make plugin ABI 
> stable" at release 1.0.
>
> Is this already implemented and just not documented?

No.

> Is there an ongoing discussion of the API that I'm missing?

There's currently no active discussion.  I think there are definitely 
some changes we want to make to the routines dissectors call that would, 
among other things, make it easier to write correct dissectors, but that 
would change the API.  I'm currently too busy to work on that, but 
hopefully I'll have some more time in the not-too-distant future.