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