Henrik Nordström wrote:
sön 2008-02-03 klockan 19:37 +1300 skrev Amos Jeffries:
Changing the MD5 affects both private and public (GET, HEAD, etc I
assume?) store MD5 functions.
You don't need to worry about the private keys. The primary input to
private keys is the runtime unique object id (m
sön 2008-02-03 klockan 19:37 +1300 skrev Amos Jeffries:
> Changing the MD5 affects both private and public (GET, HEAD, etc I
> assume?) store MD5 functions.
You don't need to worry about the private keys. The primary input to
private keys is the runtime unique object id (mem_obj->id). Having the
sön 2008-02-03 klockan 19:05 +1300 skrev Amos Jeffries:
> The problem with MD5 is what the side-effect of altering the MD5 in
> store will do. Would it make older caches after upgrade 'loose' all
> their content as never-matching-again objects?
> I don't know enough at this point to answer that
> On Sun, 2008-02-03 at 19:37 +1300, Amos Jeffries wrote:
>> >> The biggest possible hit I've seen so far with the enum change is the
>> >> store MD5's, they currently use the int value of the enum. I'm not
>> sure
>> >> if it would matter making them always use the image() string instead.
>> >> Th
On Sun, 2008-02-03 at 19:37 +1300, Amos Jeffries wrote:
> >> The biggest possible hit I've seen so far with the enum change is the
> >> store MD5's, they currently use the int value of the enum. I'm not sure
> >> if it would matter making them always use the image() string instead.
> >> They are
Alex Rousskov wrote:
On Sun, 2008-02-03 at 16:41 +1300, Amos Jeffries wrote:
Alex Rousskov wrote:
Please give an example or two, where the performance would noticeably
suffer for standard methods.
There were several switch(e->method) in what I think is the request
processing pathways. I was t
Adrian Chadd wrote:
On Sun, Feb 03, 2008, Amos Jeffries wrote:
Please give an example or two, where the performance would noticeably
suffer for standard methods.
There were several switch(e->method) in what I think is the request
processing pathways. I was thinking making that switch into a se
On Sun, 2008-02-03 at 16:41 +1300, Amos Jeffries wrote:
> Alex Rousskov wrote:
> >
> > Please give an example or two, where the performance would noticeably
> > suffer for standard methods.
>
> There were several switch(e->method) in what I think is the request
> processing pathways. I was thin
On Sun, Feb 03, 2008, Amos Jeffries wrote:
> >
> >Please give an example or two, where the performance would noticeably
> >suffer for standard methods.
>
> There were several switch(e->method) in what I think is the request
> processing pathways. I was thinking making that switch into a series o
Alex Rousskov wrote:
On Sun, 2008-02-03 at 12:11 +1300, Amos Jeffries wrote:
Alex, I'm droppign the conversion and not seeing many uses of METHOD_*
as an int. the ones present however look to be important a keepers.
You mentioned earlier when this class went it it might be an idea to
look at r
Alex Rousskov wrote:
On Sun, 2008-02-03 at 11:31 +1300, Amos Jeffries wrote:
... making access to the int value an explicit call to value() instead
of silent conversion.
How about id() instead of value()?
Much the sameness. But yes thats more logical. My head isn't working too
well this mo
On Sun, 2008-02-03 at 13:09 +1300, Amos Jeffries wrote:
> The exact errors is when compiling testHeaders_HttpRequestMethod.cc.
> The test where there is no code run, just the dependency and inline build.
>
> ./HttpRequestMethod.h: In function ‘std::ostream&
> operator<<(std::ostream&, const Htt
On Sun, 2008-02-03 at 11:31 +1300, Amos Jeffries wrote:
> ... making access to the int value an explicit call to value() instead
> of silent conversion.
How about id() instead of value()?
> But as usual I'm not expecting anyone but me will go near the code
> until its already in HEAD. :-(
Hey,
On Sun, 2008-02-03 at 12:11 +1300, Amos Jeffries wrote:
> Alex, I'm droppign the conversion and not seeing many uses of METHOD_*
> as an int. the ones present however look to be important a keepers.
> You mentioned earlier when this class went it it might be an idea to
> look at removing the _me
Amos Jeffries wrote:
Alex Rousskov wrote:
On Sat, 2008-02-02 at 13:12 +, Amos Jeffries wrote:
Update of cvs.devel.squid-cache.org:/cvsroot/squid/squid3/src
Modified Files:
Tag: ayjwork
HttpRequestMethod.cc HttpRequestMethod.h SquidString.h
String.cci Log Message:
Compile er
Alex Rousskov wrote:
I do not know what error you are getting, but it is possible that
auto-conversion from HttpRequestMethod to method_t is at fault. If so,
we should probably try to remove that conversion.
Again, let me know if you need a hand.
Thank you,
Alex, I'm droppign the conversion
Alex Rousskov wrote:
On Sat, 2008-02-02 at 13:12 +, Amos Jeffries wrote:
Update of cvs.devel.squid-cache.org:/cvsroot/squid/squid3/src
Modified Files:
Tag: ayjwork
HttpRequestMethod.cc HttpRequestMethod.h SquidString.h
String.cci
Log Message:
Compile errors. From HttpRequestMetho
On Sat, 2008-02-02 at 13:12 +, Amos Jeffries wrote:
> Update of cvs.devel.squid-cache.org:/cvsroot/squid/squid3/src
>
> Modified Files:
> Tag: ayjwork
> HttpRequestMethod.cc HttpRequestMethod.h SquidString.h
> String.cci
> Log Message:
> Compile errors. From HttpRequestMeth
18 matches
Mail list logo
