[DGD] DGD and *dbm

[Shentino]

>
>  Yes, technically you are only suggesting, but suggesting "you should do this work" is a lot like asking him to do work.
>

I remember a quote from felix including the phrase "what you have to
do is convince *me*.  Generally, you may assume that if I thought
something worthwhile, I would have implemented it myself" (sp/gr).

But I digress...

My reasons for wanting an improved extension interface *written by
felix* is that, as the author of DGD, he is in the best position to do
such an interface correctly.  Honestly, who knows the source better
than the one who wrote it?

I also figure that a beefed up extension interface, coded *once*,
would then enable many other people to implement extension modules of
their own in such a way that MP's internal rules, whatever they may
be, are followed.

Such an extension interface written by anyone else simply fails to
possess even a smidge of a guarantee of being done right.  Plus, since
DGD is constantly upgraded, any "foreign" source code would likely go
out of date extremely quickly.

In short, nobody else can do it.

> (stuff on named pipes)

Perhaps my "/socket" or "or socket" escaped attention. :P

However, portability concerns still invalidate the idea, at least as
far as catering to non-*nix'es go.

> 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?

Not exactly the *same* work.

Going back to the car/cellphone analogy, I am not asking you to
install a cellphone in the car.

It's more like I'm asking you to install, say, a <insert favorite
connection standard here> port which other companies/people could use
to plug in their own devices, which would cooperate with the car's own
electronics, in the sense that they play by the car's rules when
sending or receiving data or signals.

Useful components include cellphones, GPS, police radar, radio,
dockable laptop computer, coffee maker, <insert useful device here>.
Probably a bad list for cars, but that's likely due to using a car
analogy.

Drilling holes of my own (i.e., hacking the source) should indeed
invalidate the warranty.  However, the car's usefulness can be safely
enhanced by adding the "universal port".  It still remains the
responsibility of the end user what he or she decides to plug into the
port.

Similiarly, a beefed up extension interface would allow useful
functionality to be added by other people, and all without forcing
them to hack source code.

Given the nature of MP, there are almost certainly going to be rules
to follow with rollbacks and commits and stuff.

The network package, for instance, as it stands, has to be made as an
outright patchset against DGD source.  With the proper extension
interface, it could become a stand-alone extension, and no changes to
DGD source itself would be required.

The same is true for many other add-ons, such as sendmail, regex, and
maybe some other stuff that's sitting in /pkg.  It would also probably
be true for things which do NOT exist yet, namely support for <insert
favorite transactional database here>.

I will concede that beefing up the extension interface would be work.

A sure way to implement everything desired is to do it in an external
daemon and tell it to connect to DGD.  But doing it that way forces in
runtime overhead.  Too much stuff done outside, and one may wonder why
getting DGD involved at all is worth it.

Hmm...maybe there just isn't all that much that a beefed up extension
interface could support that isn't also crossing into the forbidden
zone of "outbound connections"

...That's it...there currently IS no useful extension (as opposed to
patch) that could benefit from a beefup that ALSO doesn't utilize
outbound connections.