On lun, 2012-01-16 at 17:01 +0100, Sven wrote: > Hi Massimo, > > yes, you are right it, we are upgrading from an ooold 'mod_dtcl' > application to rivet. :-) > > We registered ttml also as rivet type: > > AddType application/x-httpd-rivet .ttml > AddType application/x-httpd-rivet .rvt > > So nothing changes by changing the name. > BTW: Is there another difference to become/being a rvt file?
No, I don't think so. I recalled David's words about mod_dtcl and mod_rivet where he said that compatibility wasn't a concern and could be abandoned any time. > > The code is already executed in the right directory. So 'puts [pwd]' > gives the correct (intended) directory. > But your proposal to explicitly determine the path helps, e.g. for > handleBBB.ttml: > > <? > source [file join [info dirname [info script]] include.tcl] > ?> > > But what is the reason for failing with the relative pathname? The TCL > version, Rivet? I assume both - a little bit each. I would prefer to > know why the code does not work as expected. > I observed also some other "oddities". (But this may also come from a > wrong TCL understanding. May be I come later back with these.) > One of the actions needed for Apache 2.x was to implicitly chdir into the directory where the script referenced in the URL is located. It's done in mod_rivet.c at line 1793 by calling Rivet_chdir_file(r->filename) A comment also suggests this call was introduced to comply with the Apache 2.x webserver. r->filename is the path to the script referenced in the URL, Rivet_chdir_file extracts the directory name and goes into it (the code was taken from mod_ruby and probably suboptimal). In principle this information could change at every request, so I don't understand why child processes are retaining this status from request to subsequent request. Is there a bug hidden somewhere? > BTW: Unfortunately to upgrade to 8.4 is no option in the moment. The > decision is already done. :-( > > Best regards > Sven > > -- Massimo --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
