[DGD] Various questions

[bart at wotf.org]

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.
--
https://www.bartsplace.net/
https://wotf.org/
https://www.flickr.com/photos/mrobjective/