bug-gne
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gne]Distributed design


From: hooker
Subject: Re: [Bug-gne]Distributed design
Date: Wed, 28 Feb 2001 08:44:29 +0800

> --- Hook <address@hidden> wrote: > Tom
> Chance wrote:
> > > > I looked at php4 and it looks like something I
> > can
> > > > sink my teeth into and be
> > > > fairly productive (the key word) quickly.
> > >
> > > It is more powerful + intuitive than Perl, so it'd
> > be
> > > good to have GNE written in this in the end :)
> > 
> > YMMV, clearly !  Having looked into PHP, I'd
> > disagree, but that's what
> > opinions are for.
> 
> Well for web-scripting, I think it is. It's been
> designed with that in mind, which, IMHO, makes it more
> suited for web hosting. IT has been designed very well
> too. Mind you come to think of it I'm not so sure on
> the server-side scripting, like the general management
> side. There I think Perl may be more suited. What I am
> wondering is could we combine PHP and Perl, or would
> that cause us a lot of unecessary problems? Maybe it'd
> be best if we designed the system in both languages,
> and we also developed systems with XML/mySQL/TEI and
> tried them all out. 

>From what I recall of PHP, it's very good at what it does, as long as you
don't mind the concept of server side programs embedded in web pages - some
people do, but personally I don't see that as a big deal.

However, (IMO) where Perl wins is in the performance increases that you can
get relatively simply from things like mod_perl. Here at work, I'm about to
play with persistant MySQL database connections as well ... that will make
even more difference. I'm not sure to what extent PHP can be "enhanced" in
similar ways.

> I would have thought that the next year would be a
> good time to get a proven system up (Perl+ Apache+
> mod_backhand+ a simple server) and then experiment
> with different systems, so that we know from
> experience on our own project which ones work, and
> which ones would be fruitful to develop should we want
> to switch later on. Any closed options now could be
> big problems later on, I don't think we should
> discount any idea; we should just find the most
> suitable temporary solution that's guaranteed to work,
> and find people willing to develop other solutions.

Agreed. Although I can't imagine that we'd end up with closed options
anyway.

Paul



reply via email to

[Prev in Thread] Current Thread [Next in Thread]