----- Original Message -----
From: "Bryan Henderson"
Sent: Tuesday, October 21, 2003 9:40 AM
Subject: [Ethereal-dev] organizing ethereal?
> Has anyone considered breaking ethereal into manageable pieces? In a
> number of ways, it is uncommonly big:
Ethereal is big but nowhere near as big as the datasets that many ethereal
users regularely work with.
Capture files in the order of multi hundred megabytes are not uncommon.
>
> - The man page (for ethereal and tethereal) is 60,000 lines. Virtually
> all of this is descriptions of fields.
Agreed. This should go in to a separate document.
>
> I think people would find ethereal easier to work with on lots of
> different levels if 1) the source tree directory structure were deepened a
> little; 2) the executable loaded dissectors dynamically as needed; and 3)
> the filter descriptions were in a separate file, or even a whole tree.
2) would be very difficult.
All the dissectors must be loaded initially before any capture file is
opened or else the filter
engine will not work.
If ethereal does not load all dissectors initially it will not be able to
determine whether "rpc.time>0.010"
is a valid filter string or not.
The problem is even more visible for Tethereal since tethereal is single
pass and non-interactive and has
to evaluate and compile the filter string before it opens the capture file.
3) agreed.
One thing that would be very useful as well would be if the various filter
items were structured in a hierarchical way.
Currently when one opens the create filter dialogue and opens the say SMB
folder we just get a huge list of ALL
fields associated with the SMB protocol.
It would be very nice if this list would be divided into subtrees,
like using the '.' in the filter name as a separator for whatever branhc
the field belongs to.
Then if all the fields that belong to the SMB header were renamed to be
called "smb.hdr.xxx"
all these fields could then be placed under a SMB.HDR subtree in the list of
available filter names.
Same thing for fields belonging to TRANS TRANS2 etc etc.
Quite a lot of work but would be well worth it from a useability point of
view.
>
> I'm willing to work on doing this, but I thought it might have already
> been discussed and found undesirable.
sounds good.