Announcemnt: PLUG Devel Event Planner Project [was]Re: Event Planning Project

[Trent Shipley]

On Wednesday 2005-03-09 15:18, Joseph Sinclair wrote:

> There has not been a decision made regarding the development platform.
> The current suggestions are GNUe (all development would be Python) or
> J2EE (All core development would be Java, although modules could be
> written in other languages if appropriate)  The system is expected to
> incorporate (eventually) a mix of server-side and client-side code,
> possibly including a stand-alone client capable of offline use for some
> functions, a rich online interface, PDA support, and whatever other
> platform support the user community needs.

Here are some observations.

I have just opened my first LAMP account.  It occurs to me that LOTS of people 
will want to run the Fenix Event Planner in LAMP virtual hosting mode.    
LAMP limits you to PERL|PHP|Python, so you basically get a two tier system.  
There is no "special" repository for business logic or objects.  Keeping to a 
3-tier architecture is ideal, but under LAMP it will require A LOT of 
discipline.  (Part of the problem is that all three P's are too powerful.  
When you work in SQR or VBA you reach a point where you say "why I am I using 
such a feeble little server-side scripting language.  I should move up to PHP 
or maybe even write a Biz Object".)

I guess my real point is that we need to decide if this is meant to run 
virtually hosted (LAMP, which effectively means 2 tier, server side heavy), 
or 3-tier which means small shops see the event planner as a single 
stand-alone application and bigger shops run it as intranet ware.

==

If we REALLY want to be lightweight then we should design and prototype FAST.  
The need for speed heavily favors Python.  This is even more true if Python 
can be pre-byte compiled and called from a JVM.  If later we WANT to redo 
core modules to Java we should be able to do the conversion piecewise.  On 
the otherhand I am not certain we can do the reverse and convert Java 
piecewise to Python.

Agility implicitly puts a premium on keeping your options open.  It follows 
that critical decisions should be delayed as long as practical.