# extensions status, to move to pecl or to drop - Thread: https://externals.io/message/38185 - Original archive: https://news-web.php.net/php.internals/38185 - Started by Pierre Joye on 2008-06-12T14:31:51+00:00 - Messages: 33 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/38185.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #38185 — Pierre Joye — 2008-06-12T14:31:51+00:00 URL: https://externals.io/message/38185#38185 Hi, While reviewing the different extensions for the windows build, I found that many are unmaintained without any commit since year(s). Other are already removed from HEAD and some may be continued to live in core but it would require some love. * Extension being deleted (not removed, a "cvs rm" will be done) mhash, no impact as we provide a compatibility layer via ext/hash (Thanks to Scott) * Extension looking for love (if noone raises the hand, they will end in PECL too) - ncurses I can help here for the windows port and pdcurses support on unix and windows. Hartmurt agreed for the move it to pecl for 5.3. - smnp nice ext, any ISP out there willing to help? I can help for the windows support Can be moved PECL - interbase - fpdf - fbsql - sybase and sybase_ct Please let me know if you can either help to maintain an extension or if you see any issue with one of these moves. Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38186 — Brian Moon — 2008-06-12T15:35:40+00:00 URL: https://externals.io/message/38185#38186 · In reply to: #38185 Pierre Joye wrote: > - smnp > nice ext, any ISP out there willing to help? I can help for the windows support Hmm, we use this. Is it broken for 5.3 or something? What do we need to do to keep this alive? -- Brian Moon Senior Developer/Engineer ------------------------------ When you care enough to spend the very least. http://dealnews.com/ --- ## #38187 — Pierre Joye — 2008-06-12T17:10:44+00:00 URL: https://externals.io/message/38185#38187 · In reply to: #38186 Hi Brian, > Pierre Joye wrote: > > […] > > Hmm, we use this. Is it broken for 5.3 or something? What do we need to do > to keep this alive? It is not maintained, no one develops or maintains it. I successfully build it on windows using the latest snmp libs, however it would be much better if there was actually a maintainer. I sadly can't take care of it alone and it does not make sense to keep a non maintained extension in php. As snmp is not the most popular extension, I do understand that it is really helpful to have good snmp support with php. That's why I made a call for volunteers instead of putting it in the "to be moved out" category. Do you feel like you can give it some love? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38193 — johannes@php.net — 2008-06-12T21:51:35+00:00 URL: https://externals.io/message/38185#38193 · In reply to: #38185 Hi, > * Extension being deleted (not removed, a "cvs rm" will be done) > > mhash, no impact as we provide a compatibility layer via ext/hash > (Thanks to Scott) We should keep this somewhere in Siberia like we did with other extensions we removed. (PHP 4 XML stuff for instance) > * Extension looking for love (if noone raises the hand, they will end > in PECL too) > > - ncurses > I can help here for the windows port and pdcurses support on unix and > windows. Hartmurt agreed for the move it to pecl for 5.3. hm, I thought this was already done, go for it. > - smnp > nice ext, any ISP out there willing to help? I can help for the windows support Last time I checked it worked nicely and I know other user which have no problems either, so I guess there's not much maintenance needed. The only thing I see is implementing new parameter parsing API. So I don't see a reason to move it to PECL. > Can be moved PECL > - interbase > - fpdf > - fbsql > - sybase and sybase_ct Moving fpdf shouldn't be a problem, for the others I can't really judge, I don't know a user of these, but that's me. johannes --- ## #38195 — Pierre Joye — 2008-06-12T22:02:04+00:00 URL: https://externals.io/message/38185#38195 · In reply to: #38193 hi, > > > […] > > We should keep this somewhere in Siberia like we did with other > extensions we removed. (PHP 4 XML stuff for instance) I was not clear, sorry. There is no point to keep it in siberia as the whole user API will still be available. You can see this move as a dependency removal. libmcrypt is not used anymore and the ext/mhash functions will be implemented using ext/hash, in ext/hash. > > […] > > hm, I thought this was already done, go for it. It will be done shortly. > > […] > > Last time I checked it worked nicely and I know other user which have no > problems either, so I guess there's not much maintenance needed. The > only thing I see is implementing new parameter parsing API. > > So I don't see a reason to move it to PECL. But who knows which minimum snmp version should be supported (I say should not could)? What can I change on windows to support a decent snmp version (don't look at the version we used now :)? No one maintains it, the user base is relatively small (very small even). We have moved working extensions to pecl in the past because they were not maintained (and that's a very good reason). If you feel like you can help to maintain it, please do it. As I said earlier, I can give a hand to improve it and make it work smoothly on windows but I can't do it alone. > > […] > > Moving fpdf shouldn't be a problem, for the others I can't really judge, > I don't know a user of these, but that's me. I'd to wait a couple of days but I think there is no issue to move them. -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38208 — Lukas Kahwe Smith — 2008-06-14T13:24:21+00:00 URL: https://externals.io/message/38185#38208 · In reply to: #38185 > - interbase > - fbsql > - sybase and sybase_ct I think moving fbsql is quite reasonable. However interbase and sybase I do not agree with. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38211 — Pierre Joye — 2008-06-14T14:24:50+00:00 URL: https://externals.io/message/38185#38211 · In reply to: #38208 > > > > > […] > > > I think moving fbsql is quite reasonable. However interbase and sybase I do > not agree with. Who will maintain them? Who can we ask when there is issues (besides the obvious ones)? Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38212 — Lukas Kahwe Smith — 2008-06-14T14:26:48+00:00 URL: https://externals.io/message/38185#38212 · In reply to: #38211 > On Sat, Jun 14, 2008 at 3:24 PM, Lukas Kahwe Smith > wrote: > > […] > > > Who will maintain them? Who can we ask when there is issues (besides > the obvious ones)? These extension seem widely used enough that we have to make it an effort to support them. Removing them is removing a key feature our user base experts to find. Now for PHP6 I see this a bit differently, especially provided we have decent support for these databases via PDO. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38213 — Pierre Joye — 2008-06-14T14:34:12+00:00 URL: https://externals.io/message/38185#38213 · In reply to: #38212 Hi Lukas, > These extension seem widely used enough that we have to make it an effort to > support them. If it is so widely used, why noone complains about this removal? Why there is nobody taking care of the bugs or sending patches? That's why I doubt that these extensions are widely used. And if there is users, they are in controlled environments like dedicated servers or intranet and can then install them from PECL. If that makes you feel better, I can make releases in PECL and post something about their status. > Removing them is removing a key feature our user base experts > to find. Now for PHP6 I see this a bit differently, especially provided we > have decent support for these databases via PDO. I don't see them as key features, and I doubt the PDO support will be any better if no one actually care about them. It is even worst in the case of firebird as even the firebird author(s) clearly stated what they think about PDO and that they are not going to help (that's what I understand). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38214 — Rasmus Lerdorf — 2008-06-14T15:43:18+00:00 URL: https://externals.io/message/38185#38214 · In reply to: #38213 Pierre Joye wrote: > Hi Lukas, > > > > > […] > > If it is so widely used, why noone complains about this removal? Why > there is nobody taking care of the bugs or sending patches? I don't think this argument works very well. If we were to apply that in general terms, we should probably drop Windows support completely because there are pretty much no Windows users taking care of bugs, nor sending patches. There are a couple, I don't want to make their contributions seem insignificant, but the ratio of users to contributors is terrible for the Windows platform. For something like the SNMP extension, it works ok. SNMP isn't exciting in any way. I did some work on it so it got to the point where it was useful to me, and there have been a couple of requests over the years to extend it, but I think for most people it does all it needs to do. -Rasmus --- ## #38215 — Lukas Kahwe Smith — 2008-06-14T15:54:09+00:00 URL: https://externals.io/message/38185#38215 · In reply to: #38213 Hi Pierre, Like I said on IRC, if the ext end up being broken, but remain in core they can get fixed and made available easily to all users. If we move them, then this is no longer possible. We can revist this topic for PHP6, but I do not think we should start dropping these extension in 5.3. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38217 — Lester Caine — 2008-06-14T16:05:28+00:00 URL: https://externals.io/message/38185#38217 · In reply to: #38212 Lukas Kahwe Smith wrote: > > […] > > These extension seem widely used enough that we have to make it an > effort to support them. Removing them is removing a key feature our user > base experts to find. Now for PHP6 I see this a bit differently, > especially provided we have decent support for these databases via PDO. Apart from the problems created by changes made to the interbase driver in the 5.1 and early 5.2 cycle ( the 64 bit version of which STILL has not been repaired :( ) the driver still works fine with modern builds of Firebird so there as been no need to improve on it. Those of us who use it have not been persuaded that PDO has any advantage as yet, especially when you add ADOdb in as a back end, so there is NOT a suitable version of PDO for interbase/firebird and no one is working on THAT, so PLEASE do not remove the one package that is working well :( As yet we have not identified any new functions in Firebird 2.1 that can not still be accessed via current driver, so there has not even been a need to spend time building an environment in which we can compile our own copies. The binary versions supplied in Linux and Windows simply work. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38218 — Pierre Joye — 2008-06-14T16:10:52+00:00 URL: https://externals.io/message/38185#38218 · In reply to: #38214 > Pierre Joye wrote: > > […] > > I don't think this argument works very well. If we were to apply that in > general terms, we should probably drop Windows support completely because > there are pretty much no Windows users taking care of bugs, nor sending > patches. There are a couple, I don't want to make their contributions seem > insignificant, but the ratio of users to contributors is terrible for the > Windows platform. You are right, that's not a good argument. However I'm still not sure about how it helps to have it in the core. What if I release them through PECL of the current state and apply patches or write fixes if there is reports and tests? DLLs can be built as well using what we had in the last 5.2 releases. That will make no difference for the users and will ease my work (sorry to be egoist :). > For something like the SNMP extension, it works ok. SNMP isn't exciting in > any way. I did some work on it so it got to the point where it was useful > to me, and there have been a couple of requests over the years to extend it, > but I think for most people it does all it needs to do. Agreed, that's why I made a call for love first and did not work well so far. Maybe you can motivate Brian :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38219 — Pierre Joye — 2008-06-14T16:10:58+00:00 URL: https://externals.io/message/38185#38219 · In reply to: #38217 Hi Lester, > Apart from the problems created by changes made to the interbase driver in > the 5.1 and early 5.2 cycle ( the 64 bit version of which STILL has not been > repaired :( ) the driver still works fine with modern builds of Firebird so > there as been no need to improve on it. Those of us who use it have not been > persuaded that PDO has any advantage as yet, especially when you add ADOdb > in as a back end, so there is NOT a suitable version of PDO for > interbase/firebird and no one is working on THAT, so PLEASE do not remove > the one package that is working well :( You need it? Please help me to maintain and to provide reliable binaries for windows or to keep it up to date when necessary (given your comment below). > As yet we have not identified any new functions in Firebird 2.1 that can not > still be accessed via current driver, so there has not even been a need to > spend time building an environment in which we can compile our own copies. > The binary versions supplied in Linux and Windows simply work. We are very reluctant to continue to release binaries where we have zero ideas how we can update the dependencies without breaking anything in the extension or in the end user applications. I would have no problem to keep it and even to help to maintain it if (and only if) I have someone knowing firebird and its php drivers well enough to tell me if what I did works or not. It is nice to complain how useless is PDO but it is way better to actually contribute and help us to make your software working with PHP :) Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38221 — Lester Caine — 2008-06-14T17:12:46+00:00 URL: https://externals.io/message/38185#38221 · In reply to: #38219 Pierre Joye wrote: > Hi Lester, > > > > > […] > > You need it? Please help me to maintain and to provide reliable > binaries for windows or to keep it up to date when necessary (given > your comment below). WHEN there is a need to maintain it the Firebird Foundation could be persuaded to do so, the ONLY need for maintenance at the moment ids to fix bugs introduced BY the continuing unnecessary changes in each build of PHP. > > […] > > We are very reluctant to continue to release binaries where we have > zero ideas how we can update the dependencies without breaking > anything in the extension or in the end user applications. I would > have no problem to keep it and even to help to maintain it if (and > only if) I have someone knowing firebird and its php drivers well > enough to tell me if what I did works or not. > > It is nice to complain how useless is PDO but it is way better to > actually contribute and help us to make your software working with PHP > :) *I* would be more than happy to look at working on a PHP6 build of the interbase driver tailored to the UNICODE build of Firebird 2.1. That is once someone actually decides the base will be fore PHP6. I even installed a development build of PHP6 some time ago, but if there is going to be TWO versions of PHP6 then to be honest I am not interested. As soon as I can be sure that we have one base for PHP6 then I will return to that development, but PHP5.3 is just another totally unnecessary distraction. I have now got php_interbase restored on PHP5.2.x so is there any need to bother my customers with PHP5.3 - no. I'll wait now for PHP6 ..... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38222 — Steph Fox — 2008-06-14T20:06:20+00:00 URL: https://externals.io/message/38185#38222 · In reply to: #38221 Lester, hi, I even installed a > development build of PHP6 some time ago, but if there is going to be TWO > versions of PHP6 then to be honest I am not interested. There haven't been for the last couple of weeks. We're just waiting for Scott to finish with the Engine work so that we can commit the rest and make PHP core (and the core extensions) be always-on Unicode. > As soon as I can be sure that we have one base for PHP6 then I will return > to that development, but PHP5.3 is just another totally unnecessary > distraction. PHP 5.3's our *baby*!!!! I have now got > php_interbase restored on PHP5.2.x so is there any need to bother my > customers with PHP5.3 - no. I'll wait now for PHP6 ..... Poor customers. They'll miss all the benefits without the inevitable performance loss. As far as I'm aware there's nothing in PHP 6 that can't be supported from PHP 5.2.1 up, but there's plenty in PHP 5.3 that a lot of developers will like. - Steph > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/lsces/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php --- ## #38223 — Lester Caine — 2008-06-14T20:13:28+00:00 URL: https://externals.io/message/38185#38223 · In reply to: #38222 Steph Fox wrote: > As far as I'm aware there's nothing in PHP 6 that can't be supported > from PHP 5.2.1 up, but there's plenty in PHP 5.3 that a lot of > developers will like. AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN UNICODE STABLE SYSTEM AVAILABLE TODAY !!!!!! -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38224 — Lars Strojny — 2008-06-14T20:20:21+00:00 URL: https://externals.io/message/38185#38224 · In reply to: #38223 Hi Lester, Am Samstag, den 14.06.2008, 21:13 +0100 schrieb Lester Caine: [...] > AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN UNICODE > STABLE SYSTEM AVAILABLE TODAY !!!!!! Please, don't yell. KTHXBYE cu, Lars --- ## #38225 — Steph Fox — 2008-06-14T20:25:03+00:00 URL: https://externals.io/message/38185#38225 · In reply to: #38223 > > […] > > AND SHOULD BE BEING DEVELOPED IN PHP6 SO WE CAN AT LEAST GET A CLEAN > UNICODE STABLE SYSTEM AVAILABLE TODAY !!!!!! Please don't shout, thanks, I'm nursing a headache. Most of it _was_ developed in CVS HEAD, and then back-ported to 5_3 when it became clear that Unicode support is likely to take a while. Extensions don't tend to be developed that way (ever), because the PECL system is such that whatever's in CVS HEAD needs to work with the current release. But that's all changing too. - Steph --- ## #38226 — Lester Caine — 2008-06-14T20:32:59+00:00 URL: https://externals.io/message/38185#38226 Pierre Joye wrote: > What I'm asking you is to help me to actually have a controllable and > testable firebird drivers in PHP. I will do my best to help you to get > things fixed and to provide the best windows binaries. However, one > thing is sure, I can't do it alone. For two reasons, I'm not a > firebird user and I have to learn it and I do not have the time or > resources to do it. > > Please let me know if you or the firebird team is ready to help us to > improve the firebird support in php and in the end, to keep it in php. THERE IS NOTHING WRONG WITH THE CURRENT FIREBIRD SUPPORT SO WHY DO WE NEED TO IMPROVE IT? If something was missing it would be a different matter, but all that is missing is a UNICODE only base to work from. I have two problems with BUILDING windows binaries myself. Being a long time Borland C++ house all of our compile system is set up for Borland Builder5/6 and we have never moved on from that simple because all of the new work is being done as PHP web applications. I have been spending any spare time between running two businesses - neither of which earn enough to pay the mortgage on their own :( - moving the legacy windows code to Linux. And in Linux I have no problem playing with C++ code without the need for open check-book to pay M$ exhortation. The main reason for moving to PHP was to get out from under M$ but my customers still insist on using Windows even where we show that Apache/PHP/Firebird performs better on Linux. The only thing that is holding up full use of UNICODE is the useless support in PHP5 - something which I had anticipated would be solved with the release of a PHP6 beta in 2007. We are half way through 2008 and there is not even a hit of an Alpha PHP6 while PHP5 goalposts seem to be moving monthly :( Until there is a roadmap to a production release of PHP6 then I am not going to divert time to what I see as a dead end development and in the meantime I am being threatened that if I don't help with this sidetrack the one component of PHP that I consider essential will be removed :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/lsces/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #38227 — Pierre Joye — 2008-06-14T20:59:54+00:00 URL: https://externals.io/message/38185#38227 · In reply to: #38226 hi Lester, > > […] > > THERE IS NOTHING WRONG WITH THE CURRENT FIREBIRD SUPPORT SO WHY DO WE NEED > TO IMPROVE IT? If something was missing it would be a different matter, but > all that is missing is a UNICODE only base to work from. You mentioned at least one problem not fixed yet. But improving something means that it works well and it will run even better afterwards. > I have two problems with BUILDING windows binaries myself. I have three problems with you now and here: 1. You keep getting loud. I'm not blind and I can read relatively good even you write with lower cases 2. You refuse to see what I'm asking 3. You keep talking about pears when I'm asking about apples > The main reason for moving to PHP was to get out from under M$ but > my customers still insist on using Windows even where we show > that Apache/PHP/Firebird performs better on Linux. Playing off base. What I proposed you is to help us to get your software continue to run smoothly with PHP, while keeping the windows support. In the end you may even get a faster version on windows, but I suppose you don't care about that (poor customers ;). > Until there is a roadmap to a production release of PHP6 then I am not going > to divert time to what I see as a dead end development and in the meantime I > am being threatened that if I don't help with this sidetrack the one > component of PHP that I consider essential will be removed :( You are completely missing my point (and it was crystal clear). I call for help to be able to actually keep firebird/interbase support in php core and you see that as a threat. I proposed you a way to make sure that everything continue to work fine and you rejected it. Please feel free to continue to shout at us for being so mad to manage releases in time and in our free time. I'm done now with my poor attempt to solve the interbase maintenance problem. -- Pierre http://blog.thepimp.net | http://www.libgd.org --- ## #38228 — Lukas Kahwe Smith — 2008-06-14T21:00:27+00:00 URL: https://externals.io/message/38185#38228 · In reply to: #38226 > Pierre Joye wrote: > > […] > > THERE IS NOTHING WRONG WITH THE CURRENT FIREBIRD SUPPORT SO WHY DO > WE NEED TO IMPROVE IT? If something was missing it would be a > different matter, but all that is missing is a UNICODE only base to > work from. > > I have two problems with BUILDING windows binaries myself. > > Being a long time Borland C++ house all of our compile system is set > up for Borland Builder5/6 and we have never moved on from that > simple because all of the new work is being done as PHP web > applications. Lester .. everybody has work and bills to pay etc. But the fact of the matter is that PHP still needs to keep going .. and hopefully not in spite of this .. but because people make enough money using PHP that they can help in doing PHP. So Pierre is hitting on some realities. We are rebuilding the entire windows build infrastructure from scratch .. or rather the windows team is. PHP has traditionally made it really easy for people to develop apps on every OS. So supporting something just for *nix is going to confuse our user base. Of course *nix will always get the bulk of the focus, but just saying something works fine on *nix so nothing is wrong if it does not build in windows is not an option. What Pierre was also pointing out is if something is used by so few people that there is only a single person who could in theory have an interest in fixing this, but for personal reason is unable to do so because he does not have any time cycles to spare (which is of course entirely ok .. its a reality of life), then maybe this feature is not worthy of core attention. So if you or any one in the Firebird/Interbase community does have the time and skills, please make it known to him that Firebird/Interbase support is on the way out of PHP. Getting issues resolved in every other minor release is not an option. Support needs to be solid in every minor release. And while you complain about PHP 5.3 and the lack of PHP 6. It might remind you about the situation you just described. People have to juggle their PHP dev time with their professional and private life's and apparently getting PHP 6 out the door does not put food on the table for enough people. Again this sounds strikingly similar to the situation you described about why you personal have no (business) interest in working on fixing up the windows builds for PHP 5.3. So please can you stop the shouting. regards, Lukas Kahwe Smith mls@pooteeweet.org --- ## #38232 — Richard Quadling — 2008-06-15T00:45:40+00:00 URL: https://externals.io/message/38185#38232 · In reply to: #38214 2008/6/14 Rasmus Lerdorf : > Pierre Joye wrote: > > > […] > > I don't think this argument works very well. If we were to apply that in > general terms, we should probably drop Windows support completely because > there are pretty much no Windows users taking care of bugs, nor sending > patches. There are a couple, I don't want to make their contributions seem > insignificant, but the ratio of users to contributors is terrible for the > Windows platform. > I try! And as I only use MSSQL, we should drop mySQL. > For something like the SNMP extension, it works ok. SNMP isn't exciting in > any way. I did some work on it so it got to the point where it was useful > to me, and there have been a couple of requests over the years to extend it, > but I think for most people it does all it needs to do. > > -Rasmus > > > -- > > > > -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" --- ## #38243 — Timm Friebe — 2008-06-15T09:05:40+00:00 URL: https://externals.io/message/38185#38243 · In reply to: #38185 Hi, > Can be moved PECL > - interbase > - fpdf > - fbsql > - sybase and sybase_ct Sybase can be moved, it is unmaintained. I would've done this long ago if I could, karma-wise. Sybase_ct works perfectly for us at 1&1 and despite feature requests that exist and me not having put big efforts into it over the past years it serves millions of requests a day without problems. The next big step would be to add all the `if (unicode)`-stuff needed for PHP6 and/or to port it to a PDO driver, which I frankly don't have time to do. If an extension is moved to PECL, it is a bit more of a hassle to install it: Windows: instead of enabling it in php.ini you need to download the dll (not sure who builds that? Is it done automatically?) / Un*x: Get a .tar.gz, unpack, phpize, configure and make (last time I tried that didn't work for me, must've been some wrong auto-whatever). Plus I'm not sure how developing works, would you mess up your PHP checkout tree by copying the pecl/ext/XXX to php-src/ext/XXX and the running all these magic autotools? Correct me if I'm wrong here, but I guess that's what people on both sides - extension developers and PHP users - are afraid of when you announce PECL-moves, right? Before you say "PECL is not siberia" think about the following: If PECL moves wouldn't hurt the user experience for any partys involved, why would any extension live in php-src/ext/? - Timm --- ## #38245 — Hartmut Holzgraefe — 2008-06-15T10:10:03+00:00 URL: https://externals.io/message/38185#38245 · In reply to: #38185 Pierre Joye wrote: > Can be moved PECL > - interbase > - fpdf > - fbsql > - sybase and sybase_ct > > > Please let me know if you can either help to maintain an extension or > if you see any issue with one of these moves. i can help with fpdf if needed but it should go to PECL nonetheless ... -- Hartmut Holzgraefe, MySQL Regional Support Manager EMEA Sun Microsystems GmbH, Sonnenallee 1, 85551 Kirchheim-Heimstetten Amtsgericht Muenchen: HRB161028 Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer Vorsitzender des Aufsichtsrates: Martin Haering --- Next page: https://externals.io/message/38185.md?page=2