> A un moment ou il est important que l'hébergement PHP soit
> compétitif par rapport à ASP, je pense que la suppression de
> safe_mode et open_basedir n'est vraiment pas une bonne chose.
Ils ne proposent pas de retirer open_basedir, c'est même limite l'inverse. Ils veulent retirer le safe_mode qui est dûr à maintenir et pose plein de problèmes pour les hébergeurs mutualisés (alors que c'est justement la cible) pour imposer plutot l'utilisation de open_basedir (qui n'agit pas sur les même choses mais qui répond assez bien au principal de la problématique).
> extension mysql: Il va falloir utiliser Mysqli ou PDO, dont l'utilisation
> n'est pas dutout la même.
L'utilisation de mysqli est (potentiellement) exactement la même que celle de l'extension mysql. A vrai dire, à part la procédure de connexion, il n'y a à mon souvenir qu'une seule fonction qui marche différement (qui renvoit NULL à la place de FALSE).
Certes, mysqli peut faire beaucoup plus de choses, va beaucoup plus loin, mais les suites de requêtes SQL et exploitation des résultats sont presques reprenables avec un rechercher/remplacer de mysql vers mysqli.
> D'ailleurs le choix se restreint à PDO puisque plus loin on vois ça:
> move "native" non pdo extensions to pecl.
L'idée de PECL c'est à la base uniquement de différencier le cycle de release de PHP de celui des extensions. Ca n'empeche même pas les packages PHP téléchageables de fournir de base les extensions concernées.
Rien n'empêche d'installer du PECL. C'est vraiment super simple. Un des buts c'est aussi le développement de PEAR et PECL. Personne ne se plaint d'avoir à utiliser CPAN au lieu d'avoir tout dans le paquet Perl de départ.
Quoi qu'il en soit, un des objectifs de ceux qui mettent en avant cette liste c'est justement de couper les vieux trucs qu'ils ne veulent plus maintenir et qu'ils considèrent comme une mauvaise idée.
Donc oui, il y a des choses qui ne marcheront plus avec les anciennes méthodes, et ils faudra utiliser les nouvelles.
> Est il vraiment nécessaire de supprimer tout ça ? Ne serait il pas
> plus bénéfique de changer la configuration par défaut afin de
> garder une compatibilité avec les applications existantes ?
C'est ce qui est fait pour l'instant et .. ça ne marche pas.
Les gens gardent les anciens php.ini. Au final on a toujours les problèmes de portabilité, de compatibilité, et on doit toujours supporter tous les systèmes "historiques" qu'on aimerait jeter.
Cette cassure on est beaucoup à l'attendre. Certains (dont moi) l'espéraient déjà pour PHP5, et malheureusement ils n'en ont pas profité.
# safe_mode -> open_basedir
Posté par Éric (site web personnel) . En réponse au journal PHP6: Outch !. Évalué à 5.
> compétitif par rapport à ASP, je pense que la suppression de
> safe_mode et open_basedir n'est vraiment pas une bonne chose.
Ils ne proposent pas de retirer open_basedir, c'est même limite l'inverse. Ils veulent retirer le safe_mode qui est dûr à maintenir et pose plein de problèmes pour les hébergeurs mutualisés (alors que c'est justement la cible) pour imposer plutot l'utilisation de open_basedir (qui n'agit pas sur les même choses mais qui répond assez bien au principal de la problématique).
> extension mysql: Il va falloir utiliser Mysqli ou PDO, dont l'utilisation
> n'est pas dutout la même.
L'utilisation de mysqli est (potentiellement) exactement la même que celle de l'extension mysql. A vrai dire, à part la procédure de connexion, il n'y a à mon souvenir qu'une seule fonction qui marche différement (qui renvoit NULL à la place de FALSE).
Certes, mysqli peut faire beaucoup plus de choses, va beaucoup plus loin, mais les suites de requêtes SQL et exploitation des résultats sont presques reprenables avec un rechercher/remplacer de mysql vers mysqli.
> D'ailleurs le choix se restreint à PDO puisque plus loin on vois ça:
> move "native" non pdo extensions to pecl.
L'idée de PECL c'est à la base uniquement de différencier le cycle de release de PHP de celui des extensions. Ca n'empeche même pas les packages PHP téléchageables de fournir de base les extensions concernées.
Rien n'empêche d'installer du PECL. C'est vraiment super simple. Un des buts c'est aussi le développement de PEAR et PECL. Personne ne se plaint d'avoir à utiliser CPAN au lieu d'avoir tout dans le paquet Perl de départ.
Quoi qu'il en soit, un des objectifs de ceux qui mettent en avant cette liste c'est justement de couper les vieux trucs qu'ils ne veulent plus maintenir et qu'ils considèrent comme une mauvaise idée.
Donc oui, il y a des choses qui ne marcheront plus avec les anciennes méthodes, et ils faudra utiliser les nouvelles.
> Est il vraiment nécessaire de supprimer tout ça ? Ne serait il pas
> plus bénéfique de changer la configuration par défaut afin de
> garder une compatibilité avec les applications existantes ?
C'est ce qui est fait pour l'instant et .. ça ne marche pas.
Les gens gardent les anciens php.ini. Au final on a toujours les problèmes de portabilité, de compatibilité, et on doit toujours supporter tous les systèmes "historiques" qu'on aimerait jeter.
Cette cassure on est beaucoup à l'attendre. Certains (dont moi) l'espéraient déjà pour PHP5, et malheureusement ils n'en ont pas profité.