Oh clarify:
the mib-depot link should only be there IF the oid was found inside an
SNMP packet of course.
On 5/11/06, ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote:
ACK.
A feature to link hf fields to URLs would be very very useful and
should not be limited to only OIDs.
It would be nice with a generic api where one could link arbitrary
hf_fields and/or values to arbitrary URLs.
Would something similar to the PROTO_ITEM_SET_GENERATED macro be a
better solution here?
PROTO_ITEM_SET_URL ?
To explicitely set the URL for a specific field somewhere (for
example to send them to
http://wiki.ethereal.com/SMB2/How_ImpersonatingLevel_Really_works_and_what_it_means
)
It might also be useful with a generic framework how to handle URLs
for fields where there is no explicit PROTO_ITEM_SET_URL
I.e.
IF there is a PROTO_.. for this field THEN
go to that URL
FI
then also
Switch(type){
case FT_OID:
send them to alvestrand...oidvalue
or send them to mib-depot
That might require that you register multiple context specific entries
for each field
Maybe something like having the popup dialog showing
"AlgorithmIdentifier" that links to wiki.ethereal.com due to PROTO_...
"Relevant RFC" that links to www.rfc-editor.org also explicitely set by
PROTO_
"Alvestrand OID repository" since this is a FT_OID
"Mib Depot" also since this is a FT_OID and it might give us the actual
mib.
with the two last entries since type was FT_OID and preferences are
set to "If type==FT_OID then add these two links"
we should ofcourse first check with the people of those external sites
if it is ok to link our app to their site by the default preferences
sicne there are milions of ethereal users and it would be very rude to
ethereal their websites. :-(
On 5/10/06, Ulf Lamping <ulf.lamping@xxxxxx> wrote:
> 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
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
