> From: David Hampton [mailto:dhampton@xxxxxxx]
> Sent: Sunday, January 07, 2001 2:53 PM
> > 1) I like the concept, however I don't like adding another data
structure
> > to hold the dissector information. You could (should?) use the
conversation
> > data structure to implement this functionality. There is an issue with
> > retaining the settings during a 'redissect'. I would rather see a data
> > structure for the user information and an initialize routine that
creates
> > the conversations when the 'redissect' happens.
>
> Where do I look to get an understanding of the conversation data
> structure?
>
Check the files conversation.h and conversation.c in the epan subdirectory.
There is also some information about conversations in the README.developer,
but this won't have the detail that you need.
This may not be the best way to go, see my comments below. I know that I
suggested the conversation, but based upon the comments of Guy and a weekend
to think about it, I think modifying the sub-dissector tables may work
better.
>
> > 4) Change the 'protocol to decode as' to a scrolled list. I fear that
this
> > list may grow if your idea is accepted.
>
> I'm unclear on what a scrolled list is. Is it simply a list within a
> scrolled window container?
>
I'm not a GTK expert, but I believe that this is correct.
You should also look at the code that does sub-dissector registration
(epan/packet.c) and consider what changes would be need to integrate
your changes into that code. The additions you purpose are a logical
extension to that code. You have to consider
1) Finding the protocols that support sub-dissector tables.
- check the dissector_tables variable in packet.c
2) Adding the user defined values after a 'redissect'; check file.c
including ...
3) Saving sub-dissector information if there was a dissector definition
when you add the user values.
4) Restoring old values if user deletes a special definition.
Jeff Foster
jfoste@xxxxxxxxxxxx
