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

[Raymond Jennings]

You'd think that but my object manager is mostly a hook farm for the klib
that keeps a database of inheritance information.  An object "manager" in
the klib sense doesn't really "manage" objects so much as keep track of
their classes.

For the earlier point, as long as I'm not dealing with libraries that
require constructors or destructors to operate properly, my mud can work
just fine without an object manager.  I just have to do a huge recompile to
rebuild the database if I lose it, or if it gets corrupted.  Which has
happened with some bugs in the past.

and hello aidil.


On Mon, Mar 3, 2014 at 12:04 PM, Dread Quixadhal <quixadhal at gmail.com>wrote:

> Yes.  Basically, if it's something that's required by most of the entire
> system, there's not much to be gained by trying to isolate it, as
> everything has to end up funneling through it anyways.
>
> There's also the question of how often it may have to escalate privs.  In
> the case of an object manager, I'd expect it to need privs frequenly, since
> it has to manage objects which will be owned by other users.
>
>
> On Mon, Mar 3, 2014 at 1:54 PM, Raymond Jennings <shentino at gmail.com>
> wrote:
>
> > So dread, your argument for stuff being kept in System has more to do
> with
> > depended essential code and not so much minimizing the privileged
> > footprint?
> >
> >
> >
> > On Mon, Mar 3, 2014 at 8:53 AM, Noah Gibbs <noah_gibbs at yahoo.com> wrote:
> >
> > > Speaking about non-DGD settings for a moment, it's quite common to run
> > > many parts as entirely separate processes where possible.  You could do
> > > this in DGD as well, though it's not standard practice.
> > >
> > > Quixadhal's point is a good one -- isolate as much as you can, but not
> > > more :-)
> > >
> > >
> > >
> > >
> > > On Monday, March 3, 2014 7:55 AM, Raymond Jennings <shentino at gmail.com
> >
> > > wrote:
> > >
> > > Thanks.
> > >
> > > Mostly I was worried about how much code I have in System that is
> > > consequently privileged.
> > >
> > >
> > > On Mon, Mar 3, 2014 at 7:25 AM, Dread Quixadhal <quixadhal at gmail.com>
> > > wrote:
> > >
> > > > 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
> > > > >
> > > > ____________________________________________
> > > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > >
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > > ____________________________________________
> > > https://mail.dworkin.nl/mailman/listinfo/dgd
> > >
> > ____________________________________________
> > https://mail.dworkin.nl/mailman/listinfo/dgd
> >
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>