Re: [naviserver-devel] commit/naviserver: 3 new changesets

[Gustaf N. <ne...@wu...>]

yes, this has pretty much potential for various kinds of applications, 
also for templating, redirects, caching (meta data), etc. However, i 
would not recommend it for logging, since the associated values are 
server-wide values that require mutex locking (somewhat like 
hierarchical nsvs). A higher level fronted for logging should be doable 
on the tcl layer and would run essentially lock-free.

One other value of the ns_urlspace command is that it makes the urlspace 
behavior easier regression-test-able. The behavior of the urlspace is 
non-trivial, especially the interactions with the various flags. I've 
already cleaned up some broken stuff (*FAST* flag + call). There is also 
some potential to improve the code performance-wise, but first the 
detailed behavior has to be "documented" in the regression test to suite 
to avoid potentially unexpected side effects.

I've committed a first version of ns_urlspace.test, which shows already 
3 somewhat unexpected cases (marked with ###). These cases should be 
fixed (or documented), but i'll add some more test cases soon. so treat 
the code as experimental...

-g


Am 19.11.15 um 08:21 schrieb Jeff Rogers:
> Bitbucket wrote:
>> 3 new commits in naviserver:
>> https://bitbucket.org/naviserver/naviserver/commits/2758b9f8392f/
>> Changeset:   2758b9f8392f
>> User:        gustafn
>> Date:        2015-11-18 19:35:25+00:00
>> Summary:     - The new command "ns_urlspace" that allows to attach data to URLs in
>>     a hierarchical manner form the Tcl level. The command allows e.g. to
>>     write ns-perm like access control in Tcl without much hassle.
> This is very cool; it's something I've wanted to expose as a tcl api for
> a long time.
>
> A thought for a further extension to this is to make the separator
> character changeable instead of only "/", so strings represented as
> "a.b.c.d" or "a:b:c:d" could be handled too.  However, that would
> probably add a good deal of complexity that is unjustified lacking an
> actual use case.
>
> I was also thinking that the trie structure could be applicable to
> logging configurations: enabling logging for "debug/sql" and "info/*"
> but not "debug/*" would be really nice.  The "/" as a separator
> character seems odd at first, but ultimately unimportant as it conveys
> the same hierarchical information as "." or ":" would.
>
> -J
>