roxen.lists.roxen.general

Subject Author Date
Re: Lots of patches that can be integrated into Roxen 5.0 in a heartbeat Stephen R. van den Berg <srb[at]cuci[dot]nl> 12-01-2009
Martin Stjernholm wrote:
>>> commit 47bcfda8973a161dc143dc51156a6e1b7b64c58c
>>>     Tune caching for some constructs

>That's as designed: RXML tags are supposed to disable caching in the
>protocol cache if their results aren't known to be cacheable.

>In hindsight it perhaps wasn't a very wise design choice since the
>caching gets too defensive - practically no rxml code gets cached in
>the protocol cache. Instead one has to use the <set-max-cache> tag at
>the end to raise the cache time.

Which turns out to be messy at best.  I either got too little effect,
or too much effect, it was never "just right".
It's the reason I started adding the set-expr-cache (but haven't finished
that).

>It's too difficult to grasp the compatibility effects if that design
>choice is changed though, so I think it's going to stay that way for
>the time being.

That I can imagine, it took me quite a while to understand where the
problems were, and I carefully tuned it to work right for my cases.
Fully understanding it is difficult at best.

>>> commit 856cc0a4fa653f218c719a0458ac26cdf3e13a33
>>>     Tie up dangling references to threads

>I believe thread support has become a de-facto requirement, so I've
>been thinking about cleaning up all those
>"#if constant(thread_create)" instead.

I see.  Well, I never run without thread support...  Except, when running
under gdb.  Debugging a threaded program still is more painful than
debugging a single threaded one.  So in order to simplify debugging I'd
wish the no-threading support to not completely die; it is ok to state that
in a production system it should not be turned off though.

>>> commit 6d3e31155bfe696ed1a400724712f7eb269bfdaf
>>>     Eliminate dead code for sorted lists

>Indeed looks unused, but it could perhaps be useful for a sorted
>global list. Letting it be, since it isn't performance critical code.

Fine with me, however, in that same file, there are "global" variables and
class-local variables with the same name; that is confusing (at least it
was to my while I was trying to understand the code).  Please rename
the old or new ones.

>>> commit 1fb6f907b601e6e25d0a6233a2bd60c4b37746c3
>>>     Optimise globbed and non-globbed urls, also fixes overzealous lowercasing

>Not convinced this keeps the same resolution order (funky as it might
>possibly be - sorting just on the lengths of patterns containing globs
>like that).

Well, it keeps the same resolution order, except in the case where
an exact url already matches an url which would otherwise be matched
by a glob url that is longer than the exact url.
I.e. the only time this is going to differ from the preceding
algorithm is when it looks like this:

http://www.abc.com/
http://*.abc.com/veryspecialsubdir/

If a request comes in for http://www.abc.com/veryspecialsubdir/test.rxml
it would have gone to server 2 in the old algorithm, and goes to server 1
in the new algorithm.

The reasons it would be good to do it the new way is are:
a. It would save a *lot* of cycles in the hottest path, as long as you match
   exact.
b. The abovementioned case where it breaks backward compatibility is rare
   enough that it is rather unlikely that anyone constructed something like
   that, or is it?
c. I have personally experienced numerous occasions where the resolving
   order of the servers and/or redirects changed over the years in Roxen,
   usually a lot more destructive than this change (I know, weak reason,
   consider it a late-complaint ;-).

>Side note: has_value() is usually easier and more obvious to use than
>search() when you just want to detect an occurrence. It also works for
>a match at position 0.

I knew that (I once did a full-source find-and-replace in ChiliMoon for
exactly this construct), after some time not coding Pike, these function
calls tend to fade in memory :-(.

>Why do you search for "["? That's not a glob char. Is it some kind of
>ipv6 measure?

No, that's because I generally get confused what magic characters globbing
supports.
/bin/sh file globbing supports ? * and [a-z] ranges, escaping through \.
Apparently Pike globbing doesn't do the ranges, I'd consider that
confusing at best.
-- 
Sincerely,
           Stephen R. van den Berg.
Every successful person has had failures but repeated failure is no
guarantee of eventual success.