[DGD]Initializing problem
Felix A. Croes
felix at dworkin.nl
Fri Apr 20 15:36:40 CEST 2001
Stephen Schmidt <schmidsj at union.edu> wrote:
> On Fri, 20 Apr 2001, Erwin Harte wrote:
> > * In ~System/ create initd.c.
> > * In ~System/sys/ create telnetd.c
> > * In ~System/initd.c compile and initialize ~System/sys/telnetd.c
> > * From either ~System/initd.c or ~System/sys/telnetd.c register the
> > newly created alternative telnet-manager as _the_ telnet-manager by
> > the call of USERD->set_telnet_manager(...object...).
> > * From ~System/sys/telnetd.c you can now clone whichever user.c object
> > you please....
>
> That's a lot of coding that I was hoping to avoid. Somewhat
> more importantly (I enjoy this, so my coding time isn't such
> a big deal) it's a lot of complexity, a lot of places where
> I might mess up, and a lot of code a hypothetical end user
> might get lost in. As anyone who's seen Melville knows,
> I usually prefer the simple solution over the elegant one
> wherever an end user is concerned.
What is simple or elegant to you may not be the same to the end user
of Melville. What can be more simple and elegant than using a
kernel-lib based Melville with the latest version of DGD, without
having to patch anything?
> > It is of course entirely up to you to replace
> > bits and pieces of the /kernel structure...
>
> Sure, but in this case, whether I bypass /kernel/obj/user.c
> via the initd and the telnetd, or whether I just blast it
> out of my way directly, either way I'm replacing it. Either
> way, if there are changes to /kernel/obj/user.c in future
> kernel libs, my mudlib won't pick them up until or unless I
> rewrite my version of user.c. So I'm not sure that I really
> gain any extra forward compatibility by going through the
> two daemons.
To my regret there is indeed one such change in the user object
that will be part of future releases: the function connect()
in LIB_USER has been renamed to connection() to fix a bug.
Having said so, of course I want to avoid such interface changes
at almost any cost, since they would lead to precisely the trouble
that you describe.
Regards,
Dworkin
List config page: http://list.imaginary.com/mailman/listinfo/dgd
More information about the DGD
mailing list