Ethereal-users: Re: [Ethereal-users] lib-ethereal

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

From: Guy Harris <gharris@xxxxxxxxx>
Date: Thu, 11 Aug 2005 09:37:56 -0700
Jeetendra Singh wrote:
I beg to differ here. Exposing well defined interfaces for (lets say) at 
least registering dissectors, invoking dissectors, creating filters, 
Ethereal control plane commands (like start/stop capture etc) and 
allowing receipt of captured data through an API will only allow users 
to put more value add.
...and prevent Ethereal's developers from fixing known problems with 
those APIs (e.g., our handling of strings needs to be changed to handle 
multiple character encodings, the length fields in various 
"proto_tree_add..." calls and in tvb_new_subset() should be made 
unsigned and separate "to the end of the tvbuff" calls should be added 
so that we don't have to take extra care to deal with 32-bit length 
fields that might contain bad values > 2^31-1, we need to determine the 
right way to have dissectors return a "this packet is one of mine" and 
"this packet is not one of mine" indications as the current 
new_register_dissector() mechanism conflates "this packet is not one of 
mine" and "this packet is one of mine but there's no data to dissect" - 
yes, this is a real problem - etc., etc..)
 As an start, monitoring can be automated and then
are are limitless possibilities.
Am not sure, whether community is stopping the users to exploit the possibilities which this great software currently provides by not exposing the usage interfaces.
Yes, we are, and we know we are.  I, at least, consider that the right 
tradeoff, at least now.  Eventually, once we have APIs that we don't 
think have problems that would need to be fixed by changing them in 
incompatible ways, we should freeze them and publish them; however, I 
don't think we have APIs like that yet.
Am also not sure how this ties our hands? There are still well defined interfaces for doing the above stuff as far as I know.
There are interfaces for doing the above.

They are "well defined" in the sense that there are header files inside Ethereal tha declare the functions, and that the functions have particular semantics.
Wheether they are defined the way they *should* be defined is another 
matter; in some cases, they aren't.  If we freeze them now, it ties our 
hands, in that we have to support the existing interfaces indefinitely - 
we can't eliminate problematic interfaces.
So why not stabilize the interfaces and untie our hands :)
Stabilizing the interfaces to a piece of software ties the hands of the 
developers of that software; it doesn't untie them.