Zoran Vasiljevic schrieb:
> I think that old AS approach is the worst as it is really limited.
>
true. and not scalable
> The Tcl-trace based approach is better but is known to have some
> problems (I do not know which ones), yet, it is pretty powerful
> and has some other nice side-effects (less memory footprint).
> Lastly, the [ns_ictl trace] is simplest to understand and deploy
> (this is also very important) but requires rewriting of existing
> scripts and most probably needs somekind of caching to speedup
> the load process when 1000's of startup files are involved.
>
just for the record: a monster like openacs consists of 2200 files which
might
be merged into the blueprint. openacs has its own package management,
containing
currently 309 packages (from cvs head). Certainly, not many people activate
all packages.
> For me, the Tcl-trace or ns_ictl trace are the way to go.
> Looking at those two, the latter is more appealing since of the
> simplicity, but it may hit us hard speedwise. OTOH, the former
> is faster and uses far less resources but is pretty complex in
> implementation (this might be done simpler, yes, yet it is always
> going to be more complex than ns_ictl trace).
>
i would envision some mixture as a good solution, which might not be so
bloated as the AS version.
- having a kernel of functions, which are available for all connection
and schedules threads.
- having a mechanisms like a naviserver version of "package require"
which can load a "package" on demand. A package can consist
of multiple files, and might require other "packages"
i would see a "package" and the kernel in a simple version
as cat-ed files cached in nsvs.
every connection says during the start of the connection that it
requires certain packages and evals it as required. i would expect
this to reduce the memory requirements, since only needed packages
are loaded into ther interps. For loading the kernel, ns_ictl traces
might an option, these won't be so many files.
however, concerning getting openacs to work on naviserver,
i would prefer having support for some time the good old blueprint way.
there are certainly many consequences on applications using
ns_eval to update the blueprint...
-gustaf
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel
