[Encore] A Modest Proposal

[Mark A. O'Neil]

Hello all,

I am following this exchange with interest. About a year ago I had
expressed similar, though less eloquently argued, points with a focus on
the Lambda Moo engine.

So at the risk of some toe stepping:

I see here essentially Three points of discussion:
1) The engine and it's age - the engine is close to fifteen years old
with relatively minor enhancements over that time. It would benefit
from a rewrite that included current requirements and the extensibility
that a language such as Java could provide - eg: a plugin interface for
added functionally or the ability to easily replace modules to suit
individual installations..
2) The MOO system itself-not so much the MOO language, but a 
reassessment of what it is and how it can be enhanced in the current
world of immersion environs - text and  graphic eg telnet VS  something
like warcraft or even encore. Here a common exchange protocol or API
would be useful to leverage the extent base of moo code and provide a
viable base for extant MOOs , but allow for direct use of API's when
desired.
3) The integration or convergence of the MOO 'system' with the
transport protocols -telnet, http. Creation of the above would allow for
not only the continued use of tenet clients, enCore, and other HTTP
derivatives, but also allow for the creation of non 'browser' based
applications. Additionally, coupling enCore to the Moo engine in a more 
'loose' manner would facilitate development of functionality.

Thus all are interrelated and I feel none can truly move forward without
consideration of the others.

enCore is excellent at providing an easier entry point for MOO
activities leveraging the 1991 lambda MOO, but sometimes it is not best
to continue to build on the same foundation as you are then continually
forced to work within the constrains of that foundation. Often it is
worth an assessment of what has been accomplished, what to keep and what
to change - then and only then can advancement be made.

There is great potential here. I guess the question is whether pursuing 
there-engineering of lambda Moo is appropriate in the context of this 
consortium I would argue 'yes' given the tight integration. Should a 
requirements gathering and design process take place I would be happy to 
participate.

FWIW.

cheers,
-m

---
Mark O'Neil
Academic Applications Developer
Curricular Systems Engineer
Academic Computing
Dartmouth College
Hanover, NH