Gilbert,
Here is some more new stuff for RSVP. I implemented the display
filtering parts and it works very well. Kudos on a good filtering
architecture. I've attached new versions of packet-rsvp.c and
packet-rsvp.h.
Couple of comments. Firstly, I defined a bunch of hidden flags which
are just boolean flags indicating whether the message is a Path, Resv
etc. (rsvp.path indicates that it is a Path). Should we add a
FT_BOOLEAN type just for clarity & documentation purposes. It wouldn't
really be a big change.
Also, regarding the documentation (it was a good idea to automatically
generate it). The thing is, the displayed string in the tree which
matches a particular item need not be as long or descriptive as a
comment in the documentation. For example, rsvp.session is a boolean
(FT_UINT8) which indicates whether a SESSION object is present in the
message. I replaced the proto_tree_add_text which created the SESSION
subtree root with an item of the same name, which defines
rsvp.session. However, the string in the documentation ("SESSION") is
the same as the string which is displayed in the tree. My options are:
1) Leave the text as it is. The help is now not that useful.
2) Change the text to "This message contains a SESSION object". The
tree view now looks dorky.
3) Leave the proto_tree_add_text as it was (with "SESSION") and define
rsvp.session as an additional proto_tree_add_item_hidden with the
string "This message contains a SESSION object". Now I have extra
lines of code to deal with.
4) Add a field to the hf_xxx data structure which is a longer string
documenting what this field does. It can be a one- or two-sentence
thing. This string will be used in online help and in documentation.
Thoughts?
-Ashok
--
--- Asok the Intern (well, not really...) ------------------
IOS Network Protocols, Cisco Systems
250 Apollo Drive, Chelmsford, MA 01824
Ph: 978-244-8387
