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.