On Sunday 06 April 2003 10:24 pm, Greg Tyrelle wrote: > *** email@example.com 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).