[Biophp-dev] Bioinformatics.org's PHP

[biophp-dev@bioinformatics.org]

On Sunday 06 April 2003 10:24 pm, Greg Tyrelle wrote:
> *** mail-lists+biophpdev@dogphilosophy.net wrote:
>   |Actually, their server's running PHP 4.3.0, at least as of a day or two
>   | ago, so once we get to the point of having some sample programs
>   | running, they ought to work just fine.  It looks like most of the
>   | "optional" abilities are compiled in as well, though I'd prefer to
>   | stick as much as possible to stuff that'll work with a "default" build
>   | of PHP4, at least until later.
>
> Any thoughts as to what a "default" build of PHP for BioPHP will be ?

Roughly, what I'm thinking of as "default" is what you get if you
"./configure" without any additional options (though realistically if
there's a feature that nearly everyone compiles in anyway [is MySQL support
default?  I've never NOT built with it so I can't remember...] then
I'd count that, too...)

Simply put, I want to reduce to the minimum feasible the number of people
who end up grumbling because they have to compile up PHP specially in
order to use some function or other (of course, this includes the 
'use java to handle heavy processing' feature that I'm hoping to
experiment with at some point, which is one of those "very optional"
things, so I wouldn't necessarily include anything that uses it with
the "core" BioPHP modules...)

> Also: are you planning to require users to install both the apache
> module and the command line interface ? Or will development be
> targeted to one or the other ?

I'm actively avoiding targeting either one - MY focus is on the CLI, but with
the notion that the classes be designed such that there's no problem simply
"pasting" them into a webpage when people want to.  What I DON'T want to do
is have everything focussed on web pages - I think PHP's grown almost as
far beyond "web page processing" as Perl has grown beyond "generating
reports" :-)

Since most of what we're working with is "backend" type processing, 
there shouldn't really be too many places where "web or not" will
be an issue - about the only thing that comes to mind is that I think
if a class has a built in display/output function that generates HTML there
should also be one that generates the same information in plain text 
(wherever this makes sense, at least).