Tsantilas Christos wrote:
> Alex Rousskov wrote:
>> On 07/09/2009 12:06 AM, Amos Jeffries wrote:
>>> Tsantilas Christos wrote:
>>>  **  Please make fqdncache_entry / ipcache_entry public classes instead
>>> of functional structs. Some gcc complain and doxygen won't document
>>> their functions properly.
>>
>> Sorry, I am not sure what you mean. What is a "functional struct"? Do
>> you want us to replace "struct fqdncache_entry" with "class
>> fqdncache_entry" and add "public:"?
>>
>> No objections, of course, just wanted to minimize merging headaches by
>> keeping out-of-scope changes to the minimum...
>>
> I did not touch it. The struct used in many places inside squid3
> 
Please do change.
The rest of the code fails to prefix the names with "struct" the typedef 
made that possible.
Using class and public: is the C++ upgrade equivalent to the typedef and 
allows functions/methods inside the struct where I suspect the typedef 
did not.
If there are code references to "struct fqdncache_entry" or "struct 
ipcache_entry", they are well within scope of the change removing 
relevant typedefs.
FWIW: I find none in the existing code. Which makes the change safe.
>>
>>>> I also have some questions to developers:
>>>>    - In squid.conf documentation  I prepend each
>>>>      HTTP format code with [http::]
>>>>      Is it OK?
>>> Most of them yes.
>>>
>>> There are a few where http:: does not make sense at all:
>>>     ts    Seconds since epoch
>>>     tu    subsecond time (milliseconds)
>>>     tl    Local time. Optional strftime format argument
>>>     tg    GMT time. Optional strftime format argument
>>
>> Definitely.
>>
>>>     dt    Total time spent making DNS lookups (milliseconds)
>>>     ui    User name from ident
>>>     us    User name from SSL
>>
>> Yeah, at least for now.
>>
>>> These are also borderline:
>>>     >a    Client source IP address
>>>     >A    Client FQDN
>>>     >p    Client source port
>>>     la    Local IP address (http_port)
>>>     lp    Local port number (http_port)
>>>     <A    Server IP address or peer name
>>
>> Agreed.
>>
>>> I'm fine with ignoring http:: for now if people do enter it for these,
>>> so no coding change. But I don't think we should document them that way.
>>
>> Agreed.
>>
>>> I'd shift the clearly HTTP ones out to a section like you have ICAP.
>>> Leaving the rest prefix-ambiguous until something is done properly.
>>
>> Or at least remove the http:: prefix in the documentation from those
>> mentioned above.
>>
> 
> I remove the http:: prefix for the format codes mentioned above.
> But maybe the use of "http::" prefix needs more discussion...
> 
Sure.
>>
>>>   adaptation::sum_trs   /   adaptation::tt
>>
>> These are very different! Tt is a single value while adapt::sum_trs is a
>> list (of individual tr's). Adapt::sum_trs is also symmetric with
>> adapt::all_trs (also a list, but possibly with more entries).
>>
>>> Yes they are not ideal, but they are there and what people are used to
>>> for now. We can minimize confusion a bit.
>>
>> OK.
> done for total_time and size
>>
>>
>>> I think at the point you do:
>>> +    case LFT_HTTP_SENT_STATUS_CODE_OLD_30:
>>> +        debugs(46, 0, "WARNING: the \"Hs\" formating code is deprecated
>>> use the \">Hs\" instead");
>>> +        break;
>>>
>>> you could also set
>>> "lt->type = LFT_HTTP_SENT_STATUS_CODE;" to reduce the need for that
>>> OLD_30 type being used outside the parse. Particularly during the config
>>> dump later it is useful to display what its supposed to be.
>>
>> Sounds good.
> 
> My compiler (because it is very clever @#%$##$%#!) does not allow me to 
> remove the LFT_HTTP_SENT_STATUS_CODE_OLD_30 from switch statements.
Is that because of a lack of default: ?
Never mind then. Just add a note saying what compiler complains if its 
removed so I don't get just as smart and do it :)
>>
>>> I spy a goto that can die...
>>>      case CLF_NONE:
>>>              goto last;
>>> @@ -1458,7 +1863,15 @@
>>>  last:
>>>      (void)0; /* NULL statement for label */
>>> +}
>>>
>>> ==> equates to "return;".  Please check for others in that same 
>>> function.
> 
> I prefer to not touch it at this time. We can change it in trunk with a 
> separate patch.
Okay. Fair enough.
Amos
-- Please be using Current Stable Squid 2.7.STABLE6 or 3.0.STABLE16 Current Beta Squid 3.1.0.9Received on Fri Jul 10 2009 - 07:57:27 MDT
This archive was generated by hypermail 2.2.0 : Sat Jul 11 2009 - 12:00:04 MDT