[DGD] microkernel philosophy: how not to make ravioli code

[Dread Quixadhal]

Usually, it's a question of dependance.

The I3 subsystem, for example, is pretty much independant of the rest of
the mudlib.  If it goes down, it can be restarted with minimal impact on
anything else, so having it run in a way that allows it to be easily
updated and restarted is a good idea.

The object manager, OTOH, seems likely to be entwined and used through the
entire system.  So ask yourself, what happens to the mudlib when you shut
it down?  If the answer is something like "the mudlib grinds to a halt
until it comes back up", then it probably should stay as a System thing.


On Mon, Mar 3, 2014 at 10:04 AM, Raymond Jennings <shentino at gmail.com>wrote:

> So I've taken a shine to skotos's approach of putting subsystems (which
> they call modules) into separate klib users to isolate them.
>
> I've since used this method to allow them to be nuked and rebooted on
> demand, which is a nice sledgehammer for when my i3 daemon goes netdead.
>
> Is it going too far to have code isolated?  Like for example, my next idea
> is segregating the object manager away from System so that it can run as
> unprivileged code.
>
> How far is too far before you stop making good code and start making
> ravioli?
>
> I know this is a silly question but I'm new to good modularity.
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>