[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
OK, I get what you are tring to do (I think) and yes, I think Zope would be an excellent base for that. I do think that the real-time applications needed should "by-pass" Zope for the real-time work, so that you only commit to Zope for storage.
On Sunday 01 February 2004 11:00 am, Lennart Regebro wrote:
OK, I get what you are tring to do (I think) and yes, I think Zope would be an excellent base for that. I do think that the real-time applications needed should "by-pass" Zope for the real-time work, so that you only commit to Zope for storage.
Yeah, that's sounds like the right design decision. I'll have to see if somebody actually wants to write a MOO with ZODB backend, of course. ;-) As regards the "must play well with Zope OFS" constraint, *does* that actually create much of a constraint with ZODB? In other words, if I were to designate an object within the Zope OFS as the top-level object for the MOO, would it then be reasonable to have Zope able to traverse into the MOO? If so, then we start to get into the "mult-server" model that Zope uses already (e.g. HTTP, Webdav, FTP, and XML-RPC are all currently supported, MOO would just be an extra server using the same ZODB). Add a plugin MOO client (or even a standalone that can be launched from the browser), and we approach a situation where the users can just segue into MOO mode if the situation calls for it (and possibly users without MOO clients can participate through the HTTP mechanism). Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
From: "Terry Hancock" <hancock@anansispaceworks.com>
As regards the "must play well with Zope OFS" constraint, *does* that actually create much of a constraint with ZODB?
Well, since I'm not sure what you mean with "Zope OFS" I don't know. Maybe you mean the Zope Management Interface?
In other words, if I were to designate an object within the Zope OFS as the top-level object for the MOO, would it then be reasonable to have Zope able to traverse into the MOO? If so, then we start to get into the "mult-server" model that Zope uses already (e.g. HTTP, Webdav, FTP, and XML-RPC are all currently supported, MOO would just be an extra server using the same ZODB).
Yeah, I guess. But I'm not even sure how the MOO came into the discussion again. Wasn't it collaborative development we were talking about? I'm pretty sure a MOO would be a lousy environment for that. Some of the technologies are clearly helpful, but the restraints of the MUD environment would quickly get into the way.
participants (2)
-
Lennart Regebro -
Terry Hancock