Re: Portability concerns

Hello André, On 03-Aug-01 10:31:30, you wrote: >But what other issues are there? Should there not be a part of the PHP >documentation dedicated to describing all the things you should worry about >if you want to write portable code? Shouldn't there be a "portability >standard" for PHP, or is there allready one? I'm sure there must be other >things to consider than the three features/settings I have mentioned, and >getting a good overview/reference for these would be a boon to everyone >trying to write portable code. >This also cover coding practices, like using relative paths and urls rather >than static ones, maybe even using abstraction layers on top of the DB (if >using one). A lot of people uses database abstraction layers, but many of the existing database abstraction packages are not really concerned with application portability but rather just using the same set of API functions: for instance PEAR-DB almost just tries to be a look a like Perl DBI but none of these really do much to help you to develop database independent applications. Of all I know, only ADODB and Metabase really try to abstract data types so you don't have to handle the different data type representation that vary between databases. For instance, almost all SQL databases support date and time types, but you can't assure that all of them use the same date format. The packages above do that for you if not for all, at least for most data types. Metabase even goes further. Besides the application runtime API, Metabase provides a database independent way to install and maintain database schemas: tables, fields, indexes and sequences. It lets you describe your schemas in a database independent XML format. Then it creates the database structures for you without the need for the user to do any SQL programming. Besides that, if you change you database schema description, Metabase is able to alter your schema without disturbing any data added to the database after you have installed. Anyway, at least regarding database application, there seems to be no agreement to what portability features should be present in an abstraction package or else we wouldn't many of such packages, unlike Java, Perl, Python, etc.. It seems to be a waste of opportunities, but sometimes developers are more concerned with pleasing their egos and do their own abstraction package and be famous (or not) with it, rather than reaching to a consensus. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --