[DGD] DGD and *dbm

[bart at wotf.org]

On Wed, 23 Jul 2008 19:08:18 +0200, Felix A. Croes wrote
> Shentino <shentino at gmail.com> wrote:
> 
> >[...]
> > And yes, having a dedicated server is the best way to handle it (then
> > you could keep everything sealed up).  Unfortunately for us hobbyist
> > types, using a dedicated server of any sort is either a pain in the
> > rear, an exercise in genius, or a bite out of the pocket book.  Or any
> > two or even all three of the above.
> 
> Here we arrive at the heart of the matter: lacking nerve, genius or
> funds (or all three) your strategy is to persuade me to do your work
> for you?

I think this is not entirely fair. In this case, I don't think anyone is
asking you to do the actual work, rather, the question to you is to help
provide an infrastructure that allows other people then you to do the actual work.

Then, it is unreasonable to expect a hobbymud to have the funds for dedicated
hosting (even more so when considering a license that prohibits commercial
use, and yeah.. we could get a commercial license, but eh.. hobbymud?)

Its not at all unreasonable to expect them to have the time to put into doing
the work, provided the tools exist. Obviously, unless someone pays you for it,
noone has a right to demand you make those tools. Someone telling you what
tools they'd like to see isn't the same as demanding you make them however.

Obviously, your primary audience is commercial mud developers, and not us who
run hobby muds, and I accept that the requirements for that are more important
to you. Doesn't change the fact that I believe it is quite reasonable to
suggest an extension interface that does provide more flexibility then the
current one does, and to point out what kind of things would become easier to
do with DGD with such an interface.

I just happen to be lucky enough to be able to afford a dedicated server, and
to have enough time, 'nerve' and just enough knowledge to modify DGD to what I
need from it, but I strongly doubt that is the norm.

> 
> Drop the silly named pipes, it's not going to work.

This I have to agree with, esp. using named pipes for input to a mud is asking
for trouble (blocking on read when one side of the pipe isn't there for example).

Then to Shentino:

Why gdbm? Its still less capable then tdbm despite tdbm no longer being worked
on actively for a decade now :) Technically, bdb would be by far the best
choice for this (it supports multiple readers, multiple writers, has decent
multithreading support, supports nested atomic transactions etc etc, all of
those you will need for DGD/MP). Gdbm would be hardly any better then ndbm or
just dbm for this purpose.

Then, in case of *dbm and SQL, there is an additional issue, you may have to
initiate a rollback in DGD.

You can consider a database to be equivalent to a mapping (but with another
underlying mechanism to store key:value pairs). If I understand the
explanations from Felix correctly, when 2 DGD/MP threads try to access the
same mapping and one or both try to modify it at the same time, one will be
rolled back. If I understand this correctly (I can quite see why you'd have to
do this), the same must happen when 2 threads try to access the same database,
or at least the same data in the same database and one or both try to change
it. You'll have to detect this, and trigger a rollback/restart.

Obviously, locking can help a lot for detecting the problem and ensuring it
won't corrupt the data in the database, but you still have to deal with data
that is in LPC variables in case of conflict, hence having to trigger
rollback/restart.

Bart.
--
Created with Open WebMail at http://www.bartsplace.net/
Read my weblog at http://soapbox.bartsplace.net/