On Tue, Mar 26, 2013 at 2:30 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Mar 26, 2013, at 10:31 AM, Evan Huus <eapa...@gmail.com> wrote: > >> I'm not 100% convinced we should though - it would be more flexible, >> but we'd be exposing some of the guts of the dissection backend into >> 'userspace' as it were. Not a particular strong objection, but >> something to keep in mind. > > I'm not sure that field values should be thought of as an internal detail; I > could see some language bindings, for example, wanting to translate field > values into values in the language, and I could see taps wanting to request > the values of specific named fields and getting them as fvalue_t's.
I'm not sure language bindings really count, since they'll potentially need access to internal details for other reasons. Taps are a good point though. Perhaps fvalue_t's are better thought of just as the 'advanced' API for uncommon uses. > I *do* see the definition of a string value changing in the future (to > support embedded NULs, strings whose binary representation is not valid in > the encoding in question, etc.), so I don't want the current fvalue_t exposed > as an unchanging structure, but we're currently not guaranteeing source or > binary compatibility for plugins or code using libwireshark between major > versions. I expect we will never guarantee compatibility between major versions - that's part of what major versions are for, after all. ___________________________________________________________________________ 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-requ...@wireshark.org?subject=unsubscribe
