On Tue, 2008-04-15 at 11:14 -0700, Bernard Li wrote:
> Hi Carlo:
> 
> On Tue, Apr 15, 2008 at 1:11 AM, Carlo Marcelo Arenas Belon
> <[EMAIL PROTECTED]> wrote:
> 
> >  since that code has been overridden by the one in r1230, is this still
> >  relevant?
> 
> The original patch which Matt submitted (and which Brad checked in)
> had a bug which simply does not set the cookie if it exists.  This is
> simply incorrect because the content of the cookie might have changed
> and this was exactly why gridstack wasn't working.  This was fixed in
> the backport that is r1230.
> 
> However, the original idea from Matt which is to conditionally set the
> cookie is still there, it's just more strict.  And this is the issue
> we are discussing here -- how to determine the situation when the
> cookie should be set, or should we just let the cookie be set all the
> time.
> 
> >  isn't setting the cookie all the time (as you proposed), going to trigger 
> > the
> >  bug why the fix in r790 was introduced to begin with?
> 
> Yes, it would.  But I don't see any way to solve both issues.  I
> simply don't see this exponential growth of cookie using a typical
> browser like Firefox, so I am trying to get a better understanding of
> what this library Matt is working with is doing.  Otherwise, reverting
> the original patch and simply set cookie all the time seems like the
> quickest fix.
> 
> Brad, can you please get a hold of Matt to see if he has any input?


At the time we were embedding the Mozilla libraries in an Eclipse RCP
application - not Firefox; it was Seamonkey or some other
dynamically-linkable Mozilla library (Firefox libs are statically linked
on SUSE at least, at least they were back then).  IIRC this is where I
was seeing the behavior in question.  I don't know if it can be
reproduced, if more current versions of these libraries still have this
problem, etc.  I don't exactly remember the details, sorry (I should
have filed a bug, I apologize).

I'm not on that project (the Eclipse RCP app) anymore, and I don't think
there are plans to continue to access the monitoring data via a web
browser - I think they will get it via different means moving forward.
It *may* be that we were the only ones seeing the problem.

My $0.02 - revert back to what was working before.  If we see a problem,
perhaps we can do a user-agent check at that level or something else to
work around it, even if we (Novell) just do it in a patch in our version
of the RPM, if it turns out that we are the only ones seeing the
problem.



BTW, sorry for not replying earlier - I can never tell if you are
referring to me or Matt Massie. :)



-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Ganglia-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-developers

Reply via email to