I noticed that the newly back-ported adp stuff uses calls like open() and stat() instead of Tcl_OpenFileChannel() etc., and therefore wont work in a Starpack (right?) environment.
The current situation is that we swapped all (most..) of the file system calls for Tcl equivalents. One of the problems Vlad found was that actually this does have an impact on performance, and so now there are some wrappers in nsd/fastpath.c: e.g. NsFastOpen() which uses open() or Tcl_OpenFileChannel(), depending on a compile-time option. One of the things that has been bugging me is that the Tcl API is incredibly ugly, requiring Tcl objects and reference counting instead of plain old strings. So I thought it would be a good idea to fill out the file system wrappers, move them to nsd/file.c, and use them throughout the core. But now I'm wondering if that's such a good idea. Looking closer, there would still have to be #ifdef checks when calling things like Ns_ConnSendChannel() vs. Ns_ConnSendFd() in fastpath.c. And is it even necessary? If you're serving pages out of a starpack, then by definition you're not after the ultimate in speed, right? So, as the page serving code is actually very pluggable, perhaps it would be acceptable to create a module, nsstarpack (or whatever) that does the equivalent of ns_register_fastpath and would be called at startup to override that default. Same with ADP pages. What else? - The module loading stuff in modload.c. This needs to stay. It's a little uglier than it needs to be, but no big deal. - The early startup code which reads the config file and the binder file. This needs to stay for now, but you could imagine how this wouldn't matter if we turned the server into a Tcl package (next version :-). The config file, for example, requires that it be read from disk (or starpack) early, we then drop root privs, and then we create a slave interp with the ns_section and ns_param commands installed, then eval the file. It's basically all Tcl anyway, except now we do it from C. - pid file and logging. The pid stuff has been converted to Tcl VFS calls, but the logging, both error log and access log haven't. I think pid is basically the same as logging and could be the same. It's not a big deal either way, but for consistency, we could convert the pid stuff back to standard OS calls. Interestingly, the stuff in nsd/rollfile.c has been converted to Tcl VFS calls and it's kind of insane, in the sense that the log files themselves can't exist in a starpack but this code jumps through hoops to handle it. rollfile.c needs to be written in Tcl. Nice little project for someone. - Couple of loose ends: nsd/urlopen.c and nsd/tclimg.c. Not sure... Anyway, the idea is that starpacks should be supported because Zoran needs it, the Tcl file system API is ugly, and our coverage is spotty (static files work, ADP doesn't), so I'm suggesting that we drop most of the VFS calls and provide a separate implementation of static file and ADP file serving. Does this sound OK? ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ naviserver-devel mailing list naviserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/naviserver-devel
