Ulf,
Thanks for the feedback,
> 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."
Obviously I missed your point last time.
Are you suggesting a solution that would register a URL on a given hf_index,
for example, would be a more acceptable approach?
> 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
Yes it is specific to OIDs. But in dissecting ASN.1 it is very useful to
determine more information about the OIDs, even if Ethereal already knows
about them. All my use of Ethereal involves ASN.1.
> - 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 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.
OK. Sounds like the patch isn't up to scratch. I'll withdraw it.
Graeme
