[MUD-Dev] The effects of object oriented servers on the item database (Long)

[Adam Martin]

----- Original Message -----
From: "Derek Licciardi" <kressilac at home.com>
To: <mud-dev at kanga.nu>
Sent: Thursday, May 10, 2001 2:01 AM
Subject: RE: [MUD-Dev] The effects of object oriented servers on the item
database (Long)

>> -----Original Message-----
>> From: Adam Martin
>> Sent: Wednesday, May 09, 2001 5:39 PM
>> To: mud-dev at kanga.nu
>> Subject: Re: [MUD-Dev] The effects of object oriented servers on the
>> item database (Long)

>> Just wondering aloud, but what about other types, such as
>> e.g. LDAP?  Not that I've ever used it for anything MUD-related,
>> but experience developing LDAP databases in commericial
>> environments has shown it to be particularly easy to understand
>> what is going on in the database, and a lot more amenable to
>> changes than, say, relational DB's (which, correct me if I'm wrong,
>> are a dog to retro-fit with altered functionality?)

> I do not know about that particular technology.  I have heard of it
> but that is as far as I can tell you about any of it.  I would be
> interested in anything you find.

http://www.gracion.com/server/whatldap.html (also see RFC 1777, and
all those related that come after, although they tend to describe the
protocol rather than the purpose/usage)

Brief summary:

It's mainly about a query protocol and underlying database structure
that are very amenable to extremely wide distribution of the system;
you are supposed to think of all your data as being held in a global
tree, which a lot of people seem to find easy to work with (IME - feel
free to disagree!).  I have worked on projects before where we
transparently distributed the data nationally across many local
servers, with any server able to answer simple queries, but then
passing on detailed requests to the relevant other servers (but thats
a back-end, invisible implementation detail).

It also allows for very easy understanding of what is going on from a
systems-POV (compared to often extremely complex relational DBs) and
makes it easy to change how things are categorised - although this can
really upset clients if you didn't code them to adapt to such changes!

One (of several) problems is that LDAP servers tend to be
low-performance, since they can't e.g. exploit relational
knowledge. I've heard it alleged that this is a technical difficulty
only, and that the commercial LDAP servers are providing
as-good-as-relational performance, but YMWV.

My feeling is that LDAP made life much easier as a system-designer,
although the lack of constraints meant having to be more conscientious
in being strict within the design.

Adam M

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev