[Encore] Further on "A Modest Proposal"

Kevin Jepson kevijeps at telusplanet.net
Sun Aug 27 21:59:11 MDT 2006


Hi Folks
 
Thanks for the responses, much to think about there.
 
What follows is not really a response to any particular points (I'll try to
address some of them directly in other posts) as it is more of a
continuation of my original idea concerning splitting the development
streams between V5 and its successors and the V3 and V4 systems.  
 
Stepping away from the metaphor discussion :-) ...
 
What practical purpose would be served by formalizing a split?
 
There are actually several parts to this that I see.
 
First, there is continuing support and optimization for the EXISTING MOOs
that are utilizing enCore as their base DB.
 
Second, there is potentially radical changes that would allow for the
creation of new MOOs using the V4 core, hybrid systems if you will.
 
Third, there is the removal of "legacy constraints" on the development of V5
and V6 systems going forward.
 
Of these three the first is probably THE MOST IMPORTANT, in my opinion.
Existing installed and running systems are complex creations with hundreds
and thousands of hours of work.  In some cases there may be code changes
made to the core objects themselves unique to those installations. The
documentation of those changes may be minimal or non-existent. Even the
people who made the changes may no longer be anywhere nearby either,
especially in educational environments.
 
Upgrading such systems to V5, with the many changes to core objects and
radical changes to the feel and display, maybe very difficult and
potentially disastrous if not approached cautiously (with good tested
backups before even trying of course).
 
However there may be lots of optimizations, fixes, new features etc. that
can be added to these MOOs that are not a wholesale upgrade. Some may even
come from the V5 development stream. ( For example I just "lifted" a couple
such from the V5 Beta this evening. The improved @locations and @parents
commands that make a nicely formatted tree of the data. Thanks Daniel! )
Why not give these existing systems lots of options from which to choose?
 
By keeping a formal development stream for such systems we can make sure we
have a base to use for testing such optimizations before making them
available to Wizards, who may or may not be programmers themselves. Unlike
the "old days"(tm) where every MOO was unique in a short time after
start-up, primarily because they were created by the users from whole cloth,
enCore MOOs come with a frame work that can be readily built on by
NON-PROGRAMMERS. 
It is that ease of setup that makes enCore so valuable in the
educational/academic world. If we want to produce objects and procedures for
these people we have to make sure they can use them safely.   
 
Approaching the second part, radical changes to allow new MOOs built on the
V4 core, is an interest of mine.
Since we already have an installed base doing large scale work, like what
Jean Marc is doing for example, can get support. Personally I would like to
see some more work done on optimizing the enCore user interface to bring it
inline with a more text oriented mode, but that is just me :-)  The
interactivity project will be of direct use to our existing users, but only
if they work in V4 systems as well because that is where the biggest "bang
for the development buck" will be.
 
The third part is critical for future development because, as some of you
pointed out, why keep going with such an old system if newer and more
readily supported languages are available? Personally I don't disagree with
that, for NEW INSTALLATIONS.  It makes sense to have the best current
technology.  But we mustn't loose sight of the fact that the installed base
of enCore systems MAY NOT BE ABLE TO UPGRADE if the technology changes too
radically.
 
I would hate to hamstring the future development of a useful system for
educational use because we have to maintain too much backwards
compatibility.
 
Formally splitting the development streams means that each can go it's merry
way without interfering with the other.
 
This is not to say that there won't be a crossover of ideas, objects and
support. I'm not suggesting we create two separate camps with armed
frontiers between them or anything.  
 
The diversity of ideas, skills and visions of those implementing enCore
Learning Environments is wonderful. We have nowhere to go but up.
 
Let us make sure that we don't loose track of those who have already
invested a huge amount of effort in creating their existing worlds. 
 
Ciao
KJ
 
======================================================
Kevin Jepson R.E.T.
President
4K Consulting Inc.                    
An't nanum hearm deth, doth hwaet ye willath.

PHONE: (403) 875-8372
Email: kevijeps at telusplanet.net
=======================================================

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.11.6/428 - Release Date: 25/08/2006
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/encore_encore-consortium.org/attachments/20060827/ba716976/attachment.html 


More information about the Encore mailing list