BAD BAD bloat (was Re: What to do with modules now ...)

J. Kean Johnston writes: Sorry, but I consider it my job to at least try to foresee problems. If I take your assertion at face value, the next questions is, what are we getting that is comparable in value to MULE? Or even close to comparable? I think you've given us two benefits of carving up XEmacs into modules. Size and the ability for users to quickly try different features (Lucid vs. Motif dialogs). First, let's look at size. I can already compile XEmacs with or without the features I want, so I can produce a binary with a size that suits me. 256MB of SDRAM can be purchased for under US$500. I run XEmacs at home, comfortably, in 32MB of memory. This is compiled with X, Lucid widgets, database support, and support for all the image types. And the binary is statically linked. All this an it runs without swapping in 32Mb of memory. Even the dirt-cheap eMachine boxes (US$399) ship with 32MB of memory. If I can run today's XEmacs on a machine that is five years old (I can and do) and on the cheapest PC's available today, then I think we're doing all right. So I don't see in-core memory size as an issue worth addressing, unless its something we can do easily. Second, we would have the ability to try different features quickly. This sounds pretty good, but with what we have today, there isn't much choice. Lucid vs. Motif is all I can think of. Except for the dialog boxes and XIM, the Motif stuff is broken, so at best you'd get to try out some different dialog boxes and the XIM code (I don't know what XIM does). Would this be worth the work? On my 266MHz Pentium, a build from scratch takes a bit under 11 minutes. Given this, trying out a new feature set isn't much of a hardship. Using modules as you describe has a very high coolness factor, but it just seems to lack practicality. I'd be glad to hear other opinions. Maintenance. Writing it is only the beginning. The new code has to be worth the effort that it will take to maintain it years into the future.