[DGD] Various questions

[Raymond Jennings]

On Mon, Jul 30, 2018 at 10:56 AM <bart at wotf.org> wrote:
>
> On Mon, 30 Jul 2018 05:26:35 +0000, francisco del roio wrote
> > Hello,
> >
> > Firstly, sorry for the message I've sent to your private email.
> >
> > El 29/7/2018 a las 12:18, bart at wotf.org escribió:
> > > On Fri, 27 Jul 2018 21:56:10 +0000, francisco del roio wrote
> > >
> > >> where is the code under the mudlib?
> > > In general, you have 3 components:
> > > - DGD
> > > - some kind of kernel
> > > - a mudlib
> >
> > I have one more question regarding this. Is there a simpler
> > implementation of the driver/connection workflow? I mean one without
> > any bload not directly related to the runtime like control access or
> > such things.
>
> Most current libs have a model which involves both a 'low level' kernel
> connection object, and a slightly less low level 'user' object. This setup
> will at first glance look somewhat more complex than it has to be, but it
> really has to be like that in order to be able to reconnect to an already
> logged in user.
>
> The simplest setups I am aware of are either kernel lib with some small mudlib
> on top of it, or cloudlib. In all cases, you get to deal with something
> handling the inbound connection request, a connection object and a user object
> of sorts at the very least.
>
> A simpler setup is technically possible, but tends to remove functionality
> which you pretty much always end up needing, and reworking the connection code
> tends to be a major pita (I went through that twice, believe me, the upfront
> learning curve is a much much much better alternative when compared to
> reworking the connection code later on to implement the separate
> connection/user objects)
>
> And I'm afraid this is also the general message. You can either start with a
> fairly complete lib (like Gurbalib or Kotaka or such) and learn that lib and
> not concern yourself with the lower level code at least initially, or if you
> want to deal with the lower level code and start your own codebase (based on
> kernel lib or such) you will have a relatively steep learning curve upfront,
> there is simply no escaping that, and hardly any inbetween.
>
> So my suggestion is to pick one of the existing libs, and use that to learn
> how things work, and only after that (and after learning from the mistakes
> others made with those libs) would be a good moment to go build something
> yourself. Figure out the model it uses for various features, and keep in mind
> much of what is in /kernel is actually really really needed to run a mud which
> can take advantage of DGD's features. Simplifying it? Yes you can, but it will
> likely bite you unless you really understand why its there and what you give
> up by removing or simplifying things.
>
> For example, the current maintainers of Gurbalib have changed it to use 2
> levels of auto object instead of the 3 which it had when I stopped maintaining
> it. While this now works, this took more work than they expected, and results
> in a number of potential security issues (functions which have to be public
> now but could be static in the 3 level model) and in less efficient code
> (because of code having to move out of the 'real' auto object), both of which
> are difficult to fix without re-introducing that 3rd level auto object,
> through one could deal with the efficiency part by just doing away with
> security alltogether, or alternatively do away with the 'sefun simulation'
> feature which Gurbalib has.
>
> (note, you certainly can create a system with only one or 2 levels of auto
> object, and make it both secure and efficient, but.. not if you want the kind
> of security model and features Gurbalib uses, this has to do with how
> call_other() interacts with static functions in the 'real' auto object).
>
> While I am no longer involved with Gurbalib, I've been maintainer of that lib
> for quite a while. It was started in the 1990s as a learning project, and when
> I picked it up in the mid/late 2000s, about everything I've done with it was
> to make it easy to get started without having to go through that learning
> curve upfront, through actually running a serious mud with it still requires
> going through that learning curve, just at a more comfortable pace (but.. at
> the expense of also having lots of code involved which you probably are not
> going to need)
>
> So.. how did I get started? Well, I took the 2.4.5 lib for DGD, and kernel
> lib, and spent a couple weeks, full time, to figure out how both worked, and
> especially why they did or did not work for things I wanted.
> After that I spent a couple months (almost full-time) writing an alternative
> for the 2.4.5 lib, using a model much more similar to that of most current
> libs for DGD and using kernel lib for inspiration, and after that about half a
> decade on reintroducing 'complexities' which I thought I didn't need. If I had
> put those in place from the start, it might have taken more than 3 months to
> get something which more or less worked, but.. a year later it would have been
> in much better shape.

Bart's advice is good here.

Generally, given that DGD is a lower level mud server compared to
others, a couple layers of abstraction are quite helpful in keeping
your code properly organized.

> Bart.
> --
> https://www.bartsplace.net/
> https://wotf.org/
> https://www.flickr.com/photos/mrobjective/
>
> ____________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd