[DGD] Working sets and (dis)advantages of file-systems

[Steve Wooster]

The FAQ mentions that "Putting everything into the auto object increases the size of 
the working set. For a single object the difference won't amount to much, but a 
mudlib wholly designed with the idea of keeping the working set small will have a 
performance advantage." What exactly is "the working set", and how does it affect 
performance? (e.g. what affects performance more, the number of functions or the 
total size of the code they contain?)

Also, I was thinking about file-systems - specifically, about how different naming 
schemes are allowed on different OSes. For example, if you write file security code 
on the assumption that filenames are case sensitive, there may be exploits if your 
mudlib is running on windows. So then that got me wondering, why not have the 
whole file system be part of the mudlib, so it's OS independant? If I stored "files" in 
objects rather than the hard disk and allowed only admins to be able to copy between 
the mud's file system and the hard disk's file system, that could have the advantage 
that I would have complete control over naming and limitations/etc and it wouldn't 
depend on the OS... Can anybody think of any disadvantages, or anything I should 
keep in mind?

Thanks for any input!

-Steve Wooster

PS, is this list an ok place to discuss general mud design or should I focus on the 
more technical aspects? I'd love to some day implement a mud with relative naming 
(ie, a player might be known by different names to different people), but there's some 
problems I would end up with that I'm not sure how to solve.