Re: Re: downloads...genuine?
| From: | Manuel Lemos | Date: | Fri, 26 Aug 2005 05:17:51 +0000 |
| Subject: | Re: Re: downloads...genuine? | ||
| References: | 1 2 3 | Groups: | php.pecl.dev |
| Request: | Send a blank email to pecl-dev+get-2804@lists.php.net to get a copy of this message | ||
Hello Wez,
on 08/26/2005 12:28 AM Wez Furlong said the following:
Manuel, geez, did you get out of the wrong side of bed or what?No, did you? ;-) Hey, put that gun down! You would just be shooting the messenger! ;-) Wez, I understand that you rightfully take yourself pretty much as the father of PECL, so for me it is natural that you are very sensitive to the subject of awareness of PECL and its projects. However, let me tell you that I work with PHP since 1997. So, if after 8 years I am still around bringing attention to the matters that I mentioned, believe me that is because I care about PHP and its future as I always did. So, consider my message as a constructive criticism because that was my only intention. I pointed problems and in some cases I proposed solutions. If you do not agree that is fine. Opinions are like faces, everybody has their own. So, it is ok that opinions may not always converge. OTOH, I honestly wish that the PHP community really started cooperating effectively, instead of jumping on this "lets nuke each other attitude". A lot of opportunities will be wasted otherwise.
All they asked was if the numbers were accurate, not whether SDO is a knock-out success already. They certainly didn't say "anyone who thinks PECL (and our package in particular) sucks please raise their hand and give reasons why". Far from it.Sure, my point is that Matthew seems to have created high expectations on those unreliable statistics, when I believe that in fact nobody is giving him any feedback about his package. I understand that his extension awareness is directly tied to PECL awareness and PHP 5 adoption, thus my comments trying to explain the lack of interest on his extension. I honestly believe that my comments can be useful, at least to him.
On 8/25/05, Manuel Lemos <mlemos@acm.org> wrote:Maybe if you worked closely to Zend marketing department you would probably know. I have seen PECL ads in Google Adwords ads in several popular PHP sites. Google Adwords are often used to advertise in many sites of related topics by companies with low budgets . Regardless of whether Zend advertising budget is low or not, I think that is better than nothing. I do not see a reason to object to Zend advertising PECL. Personally I would advise (Zend or whoever has a advertising budget) to also use ad agencies that traditional are more effective in terms of putting up campaigns that bring better awareness, like for instance Tribalfusion or Fastclick/Valueclick. http://www.tribalfusion.com/ http://www.fastclick.com/ Many big companies use these Internet ad agencies like Oracle, Macromedia, Microsoft, etc.. I don't know about IBM or Novell that seem closer to PHP now. Maybe they prefer advertising by dealing directly with site owner companies. As for PECL ads, I cannot guarantee that if you go to this page you will see those ads, but I just visited it and it has shown an ad say something like: PECL Tutorials - Ready to use extensions, libraries and functions for PHP 4 & 5. http://www.phpclasses.org/reviews/id/1411601882.htmlI know that Zend is paying to advertise PECLI work quite closely with Zend, and I'm also somewhat intimately related to PECL(!), and this is news to me. Where did you hear this?
Wez, of course I know that, but that is not what I said. The tip that I am giving you is that in the page of each PECL package there is no link to download pre-compiled extensions, only the source in tar.gz format. See what I mean now? I know that PECL site was based on PEAR. The problem is that PEAR site did not need pre-compiled binaries links because PEAR packages are plain PHP source. As I mentioned, I know there are Windows pre-compiled binaries in snaps.php.net, but that is not mentioned in the PECL package pages.- PECL packages are not plug-and-play. It means you can't download the packages and try them right away. I know there are precompiled binaries for Windows, but even these are secret. A link to the snaps.php.net is obviously needed there.You obviously missed out on the sections in the manual that explain how to install PECL packages, and the bundle of PECL dlls available for download alongside the PHP distribution itself on the download pages.
I guess by now you understand that my suggestion to improve is to add links in each PECL package page to where an user may download pre-compiled binaries of the respective packages. That is for Windows users. For Linux/Unix users I have a slightly different idea. See below.If you go to any PECL package page all you are informed about is the download of the source code. 99.999999% of the users will do nothing with the source code because either they do not have a development environment to compile and test or do not have the knowlegde to do that.How would you improve this, bearing in mind that the PHP manual is the PHP manual and that pecl.php.net is the download page?
That is why I mentioned "at least for the main Linux distributions". Some awareness improvement is better than no awareness, which is what I believe PECL has now. I consider main Linux distributions: SuSE, RedHat and Mandriva. If people behind these distributions embrace PECL packages as they have done with PHP core, I am sure others will follow. So, maybe you (or somebody else) do not have to do anything other than contacting whoever is in charge so they pick on PECL packages and include in their distributions. Anyway, that would solve part of the problem. At least some distributions only pick one version of each package. So, they would not provide updates. Actually, at least SuSE has a directory on their projects FTP site with the latest PHP rpm packages. Ideally, I think a fake RPM package could be built so it would automatically install from the source. That would make it possible to reduce the number of RPM packages for each PECL extensions, as in theory a single RPM package would work with all distributions of the same vendor.It would be better if there were maybe a few PHP version independent rpm packages ready for download at least for the main Linux distributions.That's not a problem for PHP to solve, but rather something for people creating packages to solve. Our volunteers can't possibly support all the 3rd party distributions. Are *you* going to look after it?
Nobody is insulting anybody here. It does not matter whether there is time and people willing to work on the problems, if there is nobody that first brings up the problems and propose solutions. This is what I think I am doing as positive to help. I hope you no longer have any difficulty to realize that. -- Regards, Manuel Lemos PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ PHP Reviews - Reviews of PHP books and other products http://www.phpclasses.org/reviews/ Metastorage - Data object relational mapping layer generator http://www.meta-language.net/metastorage.html- Other reasons could be brought up, but I think the reasons above are the most important to justify the lack of interest on your package, some of which you can do something about.Rather than insulting the hard work of many people, why don't you do something positive to help?