fighting for dissector independence

[mmann78 () netscape net]

I started working on the "Fileshark" concept [1].   As part of the architecture, I don't believe "Fileshark" should 
include the dissector.lib as noted in the original discussion [2], but should include the rest of the epan directory 
($LIBWIRESHARK_OBJECTS).  I hacked the nmake configuration in an attempt to make that happen and came across a handful 
of link errors.  Below is a description and what I think should be done about them (??? means either I don't know or 
don't really like my provided solution).  Any additional suggestions (including completely different approaches) are 
welcome .

mtp3_pc_to_str_buf() - ??? The problem is that the format is determined by a preference in the mtp3 dissector, 
otherwise I would think address_to_str.c would be a fine place for the function.
 
radius_dict.c - missing "basic type handling" functions from packet-radius.c.  ??? Since radius_dict.c is 
autogenerated, make an accompanying radius_(something).c in epan directory to include the "basic type handling" 
functions
 
tcap-persistentdata.c - lists and hash tables used for tcap dissector.  Should really be in packet-tcap[-template].c

camel-persistentdata.c - same as tcap
 
print.c - hf_ fields from from frame and data dissectors in order to output data values.  ???
 
gcp.[ch] - Context tracking for Gateway Control Protocol.  Used by a few dissectors - just put the functionality in one 
of them.
 
follow.c - get_tcp_conversation_data() - move in from packet-tcp.c (some other related functionality needs to be pulled 
in too)
 
exported_pdu.c - dvbci_get_evt_from_addrs - ??? part of "address handling" of epan? to_str?
 
 

One other solution I thought of was to create a separate "grouping" in the build configuration that wouldn't have "very 
dissector specific files" in the epan directory, but I wanted to avoid that duplication (or a confusing meaning of 
"common") if possible.  Maybe expand wsutils?

[1] https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=9607
[2] http://www.wireshark.org/lists/wireshark-dev/201306/msg00101.html


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe