[DGD] Fatal error when no user object returned

[Raymond Jennings]

On Tue, Jun 5, 2018 at 9:55 PM, Dread Quixadhal <quixadhal at gmail.com> wrote:
> The only one I can really think of is that of an LPC web server.

Something that kotaka and SkotOS both implement.

> If I were working on a web server object and somehow screwed it up so the expected callback function were no longer there (IE: a typo or bad search/replace), it is unfortunate for an incoming connection on that port to shut down the entire driver, if that is indeed what happens.

Easily avoided if you code properly.  If you come up empty, just
return something that sends an error message back to the client and
then disconnects.

> I’m talking about the object compiling properly, but not being able to handle the driver apply.

See above.

> Of course, the driver can’t really know if any given connection is essential (like the login object), or something not really required (like a web server)… but I’m inclined to think it should only really be fatal during bootup, and not when it’s the result of an object update.  After all, if you screw up the login object and can’t log back in, you can always send SIGINT to the driver to force it to shutdown (or kill -9 if you really want it dead right now).

Keeping a failsafe (like the kernel library's admin back door) is
LPC's responsibility.  Especially when anything dgd side would
complicate dgd's source code.

If you don't want to shoot yourself in the foot, either aim carefully
or wear bulletproof boots.

> Either way, whether it kills itself, or you kill it, you’re going to have to dig up an older state dump to recover and lose whatever progress happened since then… assuming you’re using persistence, of course.

Backups are nice.

> It’s not a huge issue, but it seems like it makes the assumption that every listening connection is VITAL to the system’s operation.

It's not really about the connections themselves being vital, so much
as DGD needing to keep itself simple and able to trust the driver
object not to misbehave.

Complicating DGD's source code is a major no-no especially for things
that can easily be resolved in LPC.  This is felix's call, but it's
also a sound design princpile that maximizes dgd's flexibility and
minimizes the complications of keeping DGD maintained.  The less you
hard code into DGD the better, and anything that can be done in LPC
should be.

This is what I like most about DGD that you can be flexible.

But yeah, it's not so much the actual connections as it is the
principle that dgd presents an api and the driver object is supposed
to conform to it.