Terry Hancock wrote:
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.
What (if anything) would a MOO server system be more adept than a Zope server at? And would it be logical to emulate MOO-based technologies using Zope OFS as the database?
Here's my two cents on this topic, just because MOO and Zope are the two coolest environments I've used in the past decade. What follows is probably not going to win any technical merit awards: At some abstract level, the MOO server and the Zope server can be considered equivalent, because they're both OO systems (both as databases and as message-handling servers). At this level, anything sufficiently OO would qualify -- you ought to try out a similar query over on the Squeak-Smalltalk list, where they also have totally OO-based web/netservers. The real difference is that MOO and Zope have been specialized for different kinds of tasks: Zope gives you the scaffolding of an object model that makes ton of sense for a "webmaster" kind of approach. MOO gave you an object model specialized for 'location'-specific real-time interaction. The extent to which these two systems have been specialized to different ends means they would in practice suck at each other's tasks. I remember in the mid-90s there were lots of projects trying to get the MOOserver to serve webpages, and it was a simple enough thing to do, conceptually (you pretend the browser is a 'player' and deal with it conversationally). But is sucked in practice, for reasons of speed and, to a certain extent, conceptual clarity: the metaphor only went so far before getting in the way. My expectation is that trying to get Zope to work as a real-time server would be similarly frustrating, just because you'd be working against the main current of what it has evolved into. The conceptual overlap in them that you point out here, though, is a very neat intellectual space, and I'd suggest you look into Squeak and Smalltalk, the current manifestation of the common ancestor of both MOO and Zope. Squeak is still green enough to be bent in pretty much any direction, so if you've got ideas about novel communications models, it's probably a more fruitful environment, just by virtue of having less of an established set of practices governing its trajectory. - John Maxwell http://thinkubator.ccsp.sfu.ca/People/jmax jmax@sfu.ca
On Saturday 31 January 2004 07:51 pm, John Maxwell wrote:
At some abstract level, the MOO server and the Zope server can be considered equivalent, because they're both OO systems (both as databases and as message-handling servers). At this level, anything sufficiently OO would qualify
This was the revelation that was getting through to me after reading some info about MOO. Both apparently allow collaboratively editing an object tree. Both seem to treat this as the main innovation.
The real difference is that MOO and Zope have been specialized for different kinds of tasks: Zope gives you the scaffolding of an object model that makes ton of sense for a "webmaster" kind of approach. MOO gave you an object model specialized for 'location'-specific real-time interaction.
[. . .] I remember in the mid-90s there were lots of projects trying to get the MOOserver to serve webpages,
Yeah, well I think it's probably some of those projects that I'm talking about. ;-) Not MOO itself, but MOO-derivatives.
[. . .] But is sucked in practice, for reasons of speed and, to a certain extent, conceptual clarity: the metaphor only went so far before getting in the way.
My expectation is that trying to get Zope to work as a real-time server would be similarly frustrating, just because you'd be working against the main current of what it has evolved into.
So, basically, you're saying that the "real-time" interaction case is the part where Zope would be weak? I.e. basically when we approach the "chat" limit, as opposed to the "forum" or "mail" limits, where conversations are highly asynchronous.
so if you've got ideas about novel communications models, [Smalltalk/Squeak is] probably a more fruitful environment, just by virtue of having less of an established set of practices governing its trajectory.
Well, I really think Zope is for me (and the suggestion about performance regimes above supports my belief), but I'm wanting to understand where some other developers are coming from, and whether in fact, there's that much of a conceptual difference. Or from another POV, I want to be able to explain my project in their language, and understand theirs in mine. And know what is likely to be transferrable. Another question I had, was whether it made sense to embed some kind of MOO system into my project (or rather when would it make sense). It sounds like that might be advisable if I wanted to support synchronous meeting and collaboration modes. But my experience with open-source projects suggests that that isn't the mode to optimize -- although it can make sense in corporate environments. Joseph Strout wrote a MOO in Python, extending his PUB IF module. It might be interesting to see what using ZODB for persistence would do to his system (I don't think he does this now). Thanks for the information, John. Cheers, Terry -- Terry Hancock ( hancock at anansispaceworks.com ) Anansi Spaceworks http://www.anansispaceworks.com
From: "Terry Hancock" <hancock@anansispaceworks.com>
So, basically, you're saying that the "real-time" interaction case is the part where Zope would be weak? I.e. basically when we approach the "chat" limit, as opposed to the "forum" or "mail" limits, where conversations are highly asynchronous.
Yes, since Zope is built for asynchronous protocols, this is problematic in Zope. Most solution simply do this by having modules that use other protocols for this. The chats and other syncronous parts then simply run outside of Zope proper. That of course means that if you want to log the chats, some special solution is needed for that.
participants (3)
-
John Maxwell -
Lennart Regebro -
Terry Hancock