> the autoloader is so easy that everyone used to benefit from it almost > unknowingly. But it's going and we now have to find our own best > strategies and practices to address the problem. Usually it takes a few > attempts before the best approach emerges, so we should mourn the > loss and start to think in terms of what's lying ahead. I think that > regarding dynamical code loading at the abstract level all our problems > look alike. Do you feel like you want to explore this problem and > develop something to become a component of our Tcl stuff?
If we end up relying on the autoloader, which we do a little bit now, we can very easily replace the Tcl version with our own once the Tcl guys decide to ship without one. I wouldn't expect that release any time before 2020 though. In the meantime, just use the one Tcl has had for years. It's already well known and people now how to use it. Well, Tcl people at least. Tcl's autoloader is all done in the ::unknown command, so it's really nothing more than creating our own. We can even create it in the ::request namespace so as not to interfere with the global unknown, but I generally would just do it at the global scope. >> I'm following a similar path, but with a big difference: I load code >> into the global namespace only if the SeparateVirtualInterps is >> true (and I always put data into ::request). >> >> The reason is simple: if, let's suppose, someone starts a hosting >> company offering Rivet access, then unless SeparateVirtualInterps is >> true the global namespace becomes shared among different virtual >> hosts belonging to different users (as soon as requests go to the >> same Apache child, I know). Then, I *should not* put code into the >> global namespace because it could interfere with other users code. >> > > I guess SeparateVirtualInterps was introduced exactly for this purpose. Not really, no. I am of the opinion that SeparateVirtualInterps should always be on by default. I'm not sure WHY we didn't make it so when we built Rivet a decade ago, but that is my feeling today. The thing is, even if you're NOT a hosting company, you REALLY want separate interps for all of your sites. I'm a poor developer (not really, but I'm cheap), so I run all my instances on the same server. I have a dev.server.com and www.server.com all running in the same Apache server. I don't want the code of those servers getting mixed up. EVER. So I want a separate interp for each host. I actually run multiple websites off the same server / Apache instance, and despite the fact that some of them might share code, I don't want any of them bumping into each other. I think that is most people. Having everything in a single interp causes more problems for beginners, I think, because they don't understand what is going on. I myself have been bitten by this. The thing is, even with separate interps turned on, Rivet is no good for a traditional sort of hosting company where everyone shares a web server. Tcl (and Rivet by extension) allows too many commands to get at the filesystem and other goodies in the OS. There's no way to lock that down, which is why NeoWebScript used safe interpreters for every web request back in the day. Nowadays, a hosting company would just give you a virtual machine or a virtual private server and not worry about it. I still think the sensible thing is to always use a separate interp for different virtual hosts, but it would break compatibility now, so I might just make some note somewhere in the INSTALL docs for the newbies. Also, if someone has a good rundown of how you COULD share some global code (like, say, a framework) between all Apache children and interps without incurring the overhead of reloading said code everywhere, that would also be nice in the docs. Maybe Karl and the Flightaware guys have some sage advice here. D --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
