Ethereal-dev: Re: [Ethereal-dev] Updated trivial packet-sip.c [patch] (Out of the office)

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: "Greg Morris" <GMORRIS@xxxxxxxxxx>
Date: Mon, 27 Mar 2006 18:54:12 +0200
I'm sorry but I am not available from March 20th through April 17th. If you need assistance during my absence then please use my backup Darren Beckett (dbeckett@xxxxxxxxxx). I will be returning back to the office on April 18th. 


>>> ethereal-dev 03/27/06 17:53 >>>


> -----Ursprüngliche Nachricht-----
> Von: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
> Gesendet: 27.03.06 17:40:07
> An: Ethereal development <ethereal-dev@xxxxxxxxxxxx>
> Betreff: Re: [Ethereal-dev] Updated trivial packet-sip.c [patch]


> Hi,
> 
> I'm going by the comment Lars made, which mirrors proto.h:451
> 
> /** Add a hidden item to a proto_tree.
>  @deprecated use proto_tree_add_item() and a subsequent call to 
> PROTO_ITEM_SET_HIDDEN() instead */
> extern proto_item *
> proto_tree_add_item_hidden(proto_tree *tree, int hfindex, tvbuff_t *tvb,
>     gint start, gint length, gboolean little_endian);
> 
> 
> I presume you are talking about what is said in 
> http://wiki.ethereal.com/Development/DeprecatedFunctions, where it 
> suggests using generated fields as an alternative to hidden fields.  I 
> don't know why the above sequence is now recommended - perhaps it makes 
> people think harder about whether they really want a hidden field?

Why not use proto_tree_add_item_hidden() and alike: Making it "harder" to use is one reason. The other one is to reduce bloat of the myriad of proto_tree_add_... functions which makes it hard to find the right function.

Why not use hidden fields at all: The main disadvantage of hidden fields is ... that they are hidden. What's the benefit of a field "nobody" knows of, except of the dissector author? 

> 
> However, I'm trying to argue that in this case having a hidden field is 
> justified and shouldn't be visible. Several sip.auth.* fields appear 
> under 4 different sip header fields (sip.Authorization, 
> sip.Proxy-Authenticate, sip.Proxy-Authorization and 
> sip.WWW-Authenticate).  I think its illogical not to have a parent 
> sip.auth field also match against any of 4 concrete headers/containers. 
> See also these arguments 
> (http://www.ethereal.com/lists/ethereal-dev/200603/msg00484.html) I 
> wrote on Friday.
> 

I don't know the details here.

Regards,  ULFL
______________________________________________________________
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193

_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev