Beware of modules.

The current discussion about breaking up XEmacs in modules is interesting, but imhnso loses a bit when confronted to reality. Lemme remind you some basic facts of life: 1- Modules are slow. Modules must be compiled as a position independant code in order to be loadable dynamically. This is particularily bad on x86 where it hogs one register for that and hence forces the compiler to generate much less efficient code. I plan to fix that for linux in the future, but it will be a 2.3 project, and linux isn't the only OS out there. Calls to module functions can't be inlined. This, in particular, concerns Mule. Don't even _think_ about changing the current Mule macros to function calls. Or be ready to crawl. 2- Module versioning is a pain Given the current state of the code we can't expect a module to work with anything else than the executable it was compiled with (count the #ifdefs in the source). This is btw more or less the same situation than with the linux kernel. Because of that, the first problem is going to be "I downloaded XEmacs 21.6.66 and it crashes at startup - Did you check the module versions ? - Ooops sorry, there was an old condom.so there from XEmacs 21.4.2". The other problem is how to install two different versions of XEmacs simultaneously. And no, I do not mean to different version numbers. I usually have on irix 4 or 5 differently compiled XEmacs executables (with/without debugging, with/without mule, with/without gung-ho, and my personally hacked versions). All the lisp and lib-src files are shared between all of them. 3- Modules and undumping aren't really compatible Undumping requires loading a lot of lisp. Said lisp uses most of the functions that would end up in modules, hence all the modules will have to be loaded. Worse, the data and bss sections of these modules will have references to the lisp code. Do we want to write a module undumper? 4- Bloat is in the eye of the beholder Sorry to say that, but "I dont buy the argument that everything that is unused is swapped either" shows a lack of understanding of modern VMs. Unused code or data isn't swapped, it isn't loaded at all. And code pages or unmodified data pages aren't swapped but discarded. I also fail to see in which way having a 3.1Mb executable and a 1.1Mb module is any better than having a 4Mb executable including both (indirect calls to functions, lack of inlining and alignment constraints in .so have both a speed and a size cost). OG.