[sorry about the gaff of replying to an unrelated thread, that was purely accidental, I'm starting a new thread with this post to fix that problem] On Saturday 31 January 2004 10:37 am, Lennart Regebro wrote:
From: "Terry Hancock" <hancock@anansispaceworks.com>
In my research of online collaborative systems I frequently see references to MOO or MUD based systems. After some reading on the subject, it seems to me that the Zope OFS could be considered a MOO -- or at least very much like one.
Can anybody comment on that?
Well, yes. I did write a MUD in LambdaMOO once, and there are many similarities, mostly the use of simple but extensive object oriented script languages and object stores.
What (if anything) would a MOO server system be more adept than a Zope server at?
Making text-based multi-user dungeouns. That is after wall, what they were made for. :-)
Well, yeah. Duh. :-) But I was thinking more in terms of extended applications such as Supernova: http://spider.ipac.caltech.edu/staff/brundage/supernova.html (I'm pretty sure this project is dead, but I knew the people who worked on it, and I wanted to see what could be learned from it).
And would it be logical to emulate MOO-based technologies using Zope OFS as the database?
I don't think emulate is the right word. ZODB (which I assume you are referring to) is a generic object store. It would be perfectly possible to write a MUD in Python + ZODB. No problems at all.
Actually I use "ZODB" and "Zope OFS" slightly differently. ZODB can store more than the OFS, if I am not mistaken. So in fact, I did mean emulate, as in, representing a MUD-like world within a Zope server and database. But having a MOO server run on a portion of the same ZODB is another possibility, yeah. Interesting that you've written a Python MOO, there's another by Joseph Strout, too, that I know about. A little googling suggests the inheritor of this codebase is: http://doop.sourceforge.net/ Of course my connection is to the single-user derivative, PUB: http://py-universe.sourceforge.net
The rest of Zope may not be as useful for it. The permission system surely would be nice, though. A web-based MUD? Yup. Surely Zope would rule at that.
I suspect this is the regime that I'm talking about. But you have to understand that I'm not actually trying to write a MUD. I'm trying to understand systems which were derived from MUDs, but do what I'm trying to do with Zope.
I've essentially already committed to using Zope at the core of my application And you might get more helpful answers if you tell us what that application is. :-)
Well, maybe. ;-) Actually these were pretty helpful answers. The application, though, is Narya: http://www.narya.net . Yes, it's Free. No it doesn't work yet. It sort of worked for awhile, but I broke it during the badly needed re-write. However, it's getting close to working again. ;-) At least it installs and instantiates now. And the new version is in the CVS at SF, project summary: http://sourceforge.net/projects/narya-project Eventually Narya will be self-hosting, but not yet! The Narya concept for collaborative development of documents is what I call a "markup" and has more to do with versioning and attribution systems and so-called "workflow", than with MUDs. But other people are trying to do similar things, coming from a MOO background. I suspect we are trying to do the same thing, but have such different jargon (they don't know Zope and I don't know MOO), that we talk past each other. So I'm trying to resolve that, by mapping similar concepts from one to the other. OTOH, the MUD idea of having active agents ("bots") operating on the data is an awfully useful one. I call this a "Crawler" in Narya (and think of it like a Unix Daemon), but the idea of small, targeted, "character-like" agents is interesting. I don't know if it has applications yet. Certainly the idea of AI self-managing systems interests me. And it may be interesting just to conceptually flip-flop between the "file system" and "virtual world" metaphors for the data, in terms of understanding the system and what it ought to be able to do. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com