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

Matthew Brown matthew.brown at cordata.net
Fri Oct 18 16:00:22 EDT 2002


You know, of course, there's always .NET... Then you'd know it will
always be compatible.

Best regards,
Matthew Brown, President
CorData, Inc.
O: (770) 795-0089
F: (404) 806-4855
E: matthew.brown at cordata.net


-----Original Message-----
From: John Wells [mailto:jb at sourceillustrated.com] 
To: ale at ale.org
Sent: Friday, October 18, 2002 3:50 PM
To: ale at ale.org
Subject: Re: [ale] need your input on a project...


Jeff,

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


Jeff Hubbs said:
> I wouldn't turn away from Zope just on account of the threading
> issues. For one thing, the threading issues can improve and I
> understand that they are, at least at the kernel level.  For another,
> ask yourself, how many user actions per second are you going to be
> looking at?  Remember that Zope does have clustering architecture
> specifically for it that could be called into play if throwing faster
> servers at the problem isn't feasible.
>
> When you say "over 70 screens and a lot of background processing,"  it
> really makes me think of Zope.  Not only will you have tools to manage
> the 70 screens, but you have any number of hooks into and out of Zope
> to facilitate your "background processing" whether or not you utilize
> Python to do it and whether or not you offload the work to separate
> computers.
>
> - Jeff
>
> On Fri, 2002-10-18 at 15:01, John Wells wrote:
>> Guys,
>>
>> Just landed a rather large project involving converting a
>> VB/Access/Sql Server app to an open source app.
>>
>> I'm most likely going the web approach because it makes very good
>> sense in this case.
>>
>> However, this is where I'm a bit indecisive.  I've used PHP quite a
>> bit in the past, and while it's very nice for smaller projects, I
>> think it tends to get messy as the project grows.  This particular
>> app will have over 70 screens and a lot of background processing, so
>> I'm not convinced PHP is the way to go.  I also want to go OO, and
>> although PHP has limited OO capabilities, it begins to feel a little
>> Perl-y after a while
>> (<flamebait>granted, PHP's OO syntax is much cleaner than
>> Perl's</flamebait>).
>>
>> My next thought was: Gee...wish Python web programming was really
>> *There*.
>>  I looked at web programming in python briefly in the past, and it
>> seems
>> as if there was either A. cgi scripting,  or B. a number of server
>> pages-like projects, but cgi is not the way I'd like to go for
>> efficiency's sake, and the server page projects looked to be a little
>> beta-ish and not what I need for a project of this magnitude.  Then
>> there's Zope, which seems mature, but folks have mentioned problems
>> with threading and the like.
>>
>> So, finally, my last option is Java/Jsp/Servlets.  I have a lot of
>> experience in this area, so coding wouldn't be a problem.  However,
>> iirc Tomcat is not really intended for production, so I'm not sure
>> what sort of servlet/jsp containers are available (and mature) as
>> open source.
>>
>> Ultimately, I need something clean and fast, with a fairly good
>> support community.
>>
>> Any thoughts?
>>
>> Thanks for your input.  It will be greatly appreciated.
>>
>> John
>>
>>
>>
>> ---
>> This message has been sent through the ALE general discussion list.
>> See http://www.ale.org/mailing-lists.shtml for more info. Problems
>> should be  sent to listmaster at ale dot org.




---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems
should be 
sent to listmaster at ale dot org.



---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.






More information about the Ale mailing list