It seems, I am misunderstood in the first place. I never meant
to expose the interfaces in the form of APIs as they exist today. They
are certainly not *well-defined* to be frozen. But I cannot see the
reason to put the fix (if i may call them) on the back burner. We are
anyways tied to use the APIs as they exist today and also the fact if
they are changed, they have to be propagated to all the
legs/applications which are currently using them (not recommended when
we know for certain that there are problems with those APIs and they
will certainly get modified). So why not work on them to fix them in
*near* future.
As regards Ethereal's development is concerned, am not a part of it and
am also not very sure whether that will be on my agenda in future too
but as the one sitting on fence, I would like to see the ways I can
interface with Ethereal to build some value add applications. I know
there are numerous applications already available, but they are bound
either to work on captured data stored in files or to get tightly
integrated with the Ethereal GUI.
I currently have following requirements which am not sure how well to
integrate in Ethereal:
1. I would like to use Ethereal to be able to read data from a
proprietary interface which by nature is not like Ethernet for ex: lets
say a TDM interface.<>
2 .I need to include some
proprietary user information with a well defined protocol but not part
of PDU, which could be parsed
and captured.
3. I would like to be able to get the captured data online for some
real time correlation?
What is the best way of doing such changes? I will not
be sure unless I know the ethereal code or have a set of well
documented interfaces? Or am I missing something here...
best regards,
Jeetendra
Guy Harris wrote:
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.
_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users
|