Re: RE: [OID] Field Information

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