[theforum] RFC: w.e.o and l.e.o Server Integration

[William Anderson]

Dean Mah wrote:

> Topic:
> 
> It seems that no one has an argument against changing the server where
> l.e.o, d.e.o, and b.e.o are currently being hosted to ServerMatrix.
> 
> The one area of concern is what the requirements for this machine
> should be since there has been talk about using a single server rather
> than the two we have now.
> 
> Integrating the two servers into one will mean a bigger box and a
> change in platform.
> 
> 
> Options:
> 
> 1) Move l.e.o, d.e.o, and b.e.o to a Windows platform to be place with
>    w.e.o which is currently running on Windows with CF/IIS/SQL Server.

This would clearly require a huge effort to get either PHP up and running to 
manage the existing PHP-based content (deo, beo and don't forget the meo 
redirectors), get some form of MTA and mailing list manager up and running 
including carrying across all the existing subscribers and admin privileges, 
and also increasing the level of access to the weo box to allow us to 
migrate and integrate these services.  Retaining the existing access level 
to weo while requesting this option would clearly massively increase the 
risk of the 'bus scenario', or even just a delayed access scenario, where 
updates and management would be required to the services.

Sounds like way too much effort to me.

> 2) Move w.e.o to a Linux platform which is what l.e.o, d.e.o, and
>    b.e.o currently run on.

This would be my preferable long term goal, but there is clearly a large 
engineering effort to be done to migrate the current weo CMS to a CMS 
running on the same OS platform as beo/leo/deo/meo currently do.  However, I 
think the risk is lessened compared to option #1 as there are currently many 
more pairs of eyes and hands on the raq (and subsequently on the 
servermatrix platform) than there are on the weo box.

> 3) Defer the decision and just move l.e.o, d.e.o, and b.e.o with the
>    intention of re-visiting the issue either through another migration
>    or by going to a distributed computing model.

 From the point of Just Getting Things Done, this is preferable, but I think 
we should be taking a long term view here.  We have decided to embark on two 
or three major projects - the first is the possible CMS rewrite/migration, 
and two relatively firmly decided a long time ago: the *eo redesign and 
evolters.org.  I would not like to have to go through a migration from the 
raq to another Linux box, and then have to go through another engineering 
effort to redesign everything to cater for a redesigned back end and 
display/render front end.

> 4) ...

Here's how I think things should go without regard to, or intention to 
bruise egos.

Project Revolt:

- immediately implement a new community-funded hosting platform
   which maximises our return on investment - i.e. favour an open-
   source OS if it allows us to reuse funds which may have been
   allocated for OS licence fees; a package which takes advantage
   of any discounts, offers, etc we can get, etc.

- immediately spec and implement a design-independent system to
   manage beo, leo and deo using a similar PHP-based backend, but
   retaining the capability to massively change the render output
   to accomodate an *eo design change

- immediately make a choice to retain the existing weo CMS, or
   migrate it to the new hosting platform - this is, at a higher
   level, a choice to fully rely on the community-funded hosting
   platform, or continue to rely on a goodwill hosting platform.

   - if the choice is made to retain the existing CMS, immediately
     spec and implement an increased level-of-access programme to
     allow greater numbers of eyes and hands on both the weo box
     and weo codebase

   - if the choice is made to migrate the CMS to the new hosting
     platform, immediately begin a scoping and design process to
     identify and consider implementing a CMS which will meet the
     existing CMS process and functionality level, while retaining
     or increasing both performance and functionality improvement
     capability.  In line with the redesign process, the CMS will
     be integrated into any redesign, and a working prototype will
     be produced within an agreed timeframe

- immediately migrate leo services to the new hosting platform,
   taking into consideration third-party services which we host
   based on goodwill (i.e. css-d) and enable them as soon as
   possible with full regard to time for testing, etc.

   while leo services are being migrated, modify the lists available
   as previously agreed upon as part of the reduction-of-levels
   discussion

- plan *eo redesign with scoping and continuance of previous
   design mockups with a view to a working prototype within
   an agreed timeframe.

- plan evolters.org in parallel with the redesign process with a
   view to a working prototype within an agreed timeframe.

Did I miss anything?

-- 
_ __/|  William Anderson      | Brodie: The Force is strong with this one
\`O_o'  neuro at well dot com |    Jay: Dude, don't encourage him
=(_ _)= http://neuro.me.uk/   |  -- Mallrats, (1995)
    U  - Thhbt! GPG 0xFA5F1100 |