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

Wed Mar 9 16:28:02 2005

This is a multi-part message in MIME format.
--------------080704070007080807020008
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

I don't see this being a system that would be appropriate for LAMP (BTW, 
LAMP is implicitly 1-tier, not 2-tier.  Even with client side scripting, 
the architecture is topologically a single tier with ancillary antecedents)
As far as virtual hosting, more and more hosting providers are offering 
J2EE (usually JBoss or JOnAS) as an option on their Linux-based hosts, 
so I don't see that as being a significant limitation.
The market for event planning is not a mass market in the business 
sense, so having a slightly more limited platform choice is acceptable 
so long as it improves coherency of design, hence the option to develop 
as a GNUe module.

The current suggestion that uses Python (GNUe) does not improve the 
speed of development over J2EE, and it also does not offer the option of 
a later move to Java, as GNUe will never support it (AFAICT).
The choice of language and platform is more dependent on architecture 
than speed of development, as the former has a lot more impact on the 
quality of the final result.

I'm primarily expecting this to appeal to a combination of small groups 
(like PLUG) who would probably run it on a spare system somewhere, and 
large enterprises (who would likely set up a dedicated intranet 
system).  If we decide to expand the focus, then we need to be much more 
careful how we design to ensure the system is usable on a wider variety 
of platform options, not fewer.

IMNSHO agility actually puts a premium on clean architecture, 
discipline, clear design, and real results; certain decisions, platform 
in particular, are tightly tied to the architecture chosen if these 
goals are to be met.  This is one of the reason why ports of software 
from one platform (i.e. .Net) to another (i.e. LAMP) rarely do well.

==Joseph++

Trent Shipley wrote:

>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.
>_______________________________________________
>PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
>http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>
>  
>

--------------080704070007080807020008
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
 <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I don't see this being a system that would be
appropriate for LAMP (BTW, LAMP is implicitly 1-tier, not 2-tier.  Even
with client side scripting, the architecture is topologically a single
tier with ancillary antecedents) 
As far as virtual hosting, more and more hosting providers are offering
J2EE (usually JBoss or JOnAS) as an option on their Linux-based hosts,
so I don't see that as being a significant limitation. 
The market for event planning is not a mass market in the business
sense, so having a slightly more limited platform choice is acceptable
so long as it improves coherency of design, hence the option to develop
as a GNUe module. 
 
The current suggestion that uses Python (GNUe) does not improve the
speed of development over J2EE, and it also does not offer the option
of a later move to Java, as GNUe will never support it (AFAICT). 
The choice of language and platform is more dependent on architecture
than speed of development, as the former has a lot more impact on the
quality of the final result. 
 
I'm primarily expecting this to appeal to a combination of small groups
(like PLUG) who would probably run it on a spare system somewhere, and
large enterprises (who would likely set up a dedicated intranet
system).  If we decide to expand the focus, then we need to be much
more careful how we design to ensure the system is usable on a wider
variety of platform options, not fewer. 
 
IMNSHO agility actually puts a premium on clean architecture,
discipline, clear design, and real results; certain decisions, platform
in particular, are tightly tied to the architecture chosen if these
goals are to be met.  This is one of the reason why ports of software
from one platform (i.e. .Net) to another (i.e. LAMP) rarely do well. 
 
==Joseph++ 
 
Trent Shipley wrote:
<blockquote cite="mid200503091619.48555.tshipley@deru.com" type="cite">
 <pre wrap="">On Wednesday 2005-03-09 15:18, Joseph Sinclair wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.
_______________________________________________
PLUG-devel mailing list - <a class="moz-txt-link-abbreviated" href="mailto:PLUG-devel@lists.PLUG.phoenix.az.us">PLUG-devel@lists.PLUG.phoenix.az.us</a>
<a class="moz-txt-link-freetext" href="http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel">http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel</a>

  </pre>
</blockquote>
</body>
</html>

--------------080704070007080807020008--