Graeme Lunt wrote:
I have just checked the change in to provide the "Field Information" context
menu item (18125).
I've added the function to oid_resolv.[ch] rather than packet-ber.[ch] as
you suggested.
However this means the URL template is not (currently) configurable as I
didn't know where "OID" preferences should appear. Any suggestions?
For now the URL template is fixed to the www.alvestrand.no site (which
contain links to the elibel site).
Hmmm, I'm a bit disappointed by your current solution as it is very
specialized. To quote my previous mail:
"I would think to have a clean mechanism to set a specific help URL
corresponding to a protocol tree item is the more important part for now."
Well, your implementation is the opposite:
- "Field Information" suggests a general purpose mechanism, but it's
(currently?) limited in effect to the FT_OID fields so for most Ethereal
users pretty useless
- No one else can add URLs in the way you've implemented it, as it would
require to add a new FT_... value (which would be a very bad idea only
for this reason)
- the "Field" in "Field Information" is just duplicated information ->
better: "Related Information"?
I have another change (which I haven't checked in) that introduces a new
field type for URIs (FT_URI) . This allows the new "Field Information" menu
item to then bring up the indicated location. My particular interest is the
URI form of a GeneralName which is used in a number of X.509 certificate
extensions.
But is a URI field type a sensible addition?
I don't see a need for a FT_URI. This would make it impossible to attach
a URL to an existing proto_item (e.g. a FT_UINT8). A better idea might
be to use a FI_URI, working much like the FI_GENERATED flags. Or am I
wrong here and this should really be dealt like the FT_NUM?
So the way you've implemented it, the whole thing is pretty much incomplete.
Regards, ULFL
