[ale] need your input on a project...

[James P. Kinney III]

Given the size of the user base, and its distributed nature, I would be
looking at the KISS principle very hard. There are plenty of reasons not
to use behemoths like Zope. The main one is it still has issues with
scaling. I have yet to see stats on a Zope installation that was
encouraging in terms of performance.

Design the screens in HTML with standard placeholders for input data. A
bit of perl to insert the data into the place holders and extract the
data back from the user forms. Save the heavy lifting for the compiled C
code interfacing with the database backend. The C code dumps output to
perl objects for the splice -n- dice onto the HTML templates.

I like the 3 tiered approach. OOP is not a solution. It's just a method.


> Like I said...I think Zope would be a good fit.  However, this app is
> for a large company with approx. 30 locations nationwide, and many
> people (some have 300+) at those locations will be using the system.
> Not sure if the Zope issues are dramatic enough to degrade performance
> at that load, but I'd hate to find that out two months into the project
> ;-).
> 
> Thanks,
> 
> John

-- 
James P. Kinney III   \Changing the mobile computing world/
President and CEO      \          one Linux user         /
Local Net Solutions,LLC \           at a time.          /
770-493-8244             \.___________________________./

GPG ID: 829C6CA7 James P. Kinney III (M.S. Physics)
<jkinney at localnetsolutions.com>
Fingerprint = 3C9E 6366 54FC A3FE BA4D 0659 6190 ADC3 829C 6CA7 



 This is a digitally signed message part