Re: [PHP4BETA] php and MS SQL Server....

From: Date: Thu, 02 Mar 2000 01:08:11 +0000
Subject: Re: [PHP4BETA] php and MS SQL Server....
References: 1  Groups: php.version4 
Request: Send a blank email to php-version4+get-11309@lists.php.net to get a copy of this message
Hello Rasmus, On 01-Mar-00 17:35:11, you wrote: >> CVS? Why? AFAIK CPAN does not require contributors to put their code >> under a CPAN managed CVS repository and I don't see a reason to have one. >So when stuff breaks you have a chance of figuring out why it broke. Just >because CPAN doesn't do it doesn't mean it isn't a good idea to do. PHP >wouldn't be with us today without CVS. I don't see how PEAR modules would >not get the same benefit. Hey, I know what CVS is for. I use it everyday since the last 3 years in my projects. My personal CVS repository has over 15MB. I just don't think it makes much sense to keep someone else's code in repository unless the developer is willing to cooperate in it's development with others. The way I see it, unless you want to block the access to PEAR CVS repository to anybody outside the core developers, you are pushing PEAR as a repository for code that developers have to give away loosing the control of its development to have it accepted in PEAR. CPAN doesn't put someone else's code under CVS because they are just a means of distribution of code, not a way to take over the development of everybody's packages. >> Unless you mean to put only PHP code of core developers in the PEAR, I >> don't see much point in putting contributors code in a CVS repository. >> A simple upload form would be much simpler and would leave out many of >> the potential contributors as you only need a Web browser, not a properly >> set CVS client. >An upload form does not exclude the code ending up in CVS. Of course, but doing so you are assuming that each contributor is willing to give up the control of the code that he has developed, probably under his own CVS respository eventually trashing the original CVS version tags. Maybe you haven't thought of this since nobody is doing it as you want, but how the original developer is supposed to keep track of the versions of his source files when your CVS repository will overwrite the original version tags? Nah, I don't think putting contributions in the CVS respository is a good idea to start with. >> For instance my PHP classes repository, code is divided by packages. Each >> author may upload one or more packages. Each package consists of one or >> more files. Each package may be classified in one or more groups and each >> author may change that classification any time. >> >> A good thing, and a reason for which I did not use PX to upload my code, is >> that when a new class is added or changed, users subscribed to the site get >> notifications by e-mail regarding the changes that were done. This saves a >> lot of time to users looking for the latest version of their favourite >> classes, and authors notifying everybody. Soon, I will have a page that >> lists the lately uploaded classes for people that don't want to get the >> notifications by e-mail. >This also annoys a lot of people. We have discussed this before, but I >refuse to register somewhere just to download code and as such your code I don't see a point there. You have probably subscribed (supplied your e-mail address) to tens of mailing lists to get often more noise the sound, and you have a problem to subscribe to one site that provides you free code right away?!? The only good reason for you to not subscribe to a site like this, is because you are not interested in its content at all, or you are interested in its content but don't want the content provider to know about it. In that case, there is little point in arguing that is annoying to people. In the Internet it was created a misconception that everything has to be free and you should be able to get it without having at least to let the provider that you are using it. What do you want next? Have a bunch of slaves working for you for free without a minimal recognition or moral compensation? The site just works that way because before people had to mail me to get the stuff that I have developed for free. That way I could keep track of people who got it by having them listed in a personal mailing list. When a new version was made available I would just need to send a message to all of them. The problem is that I was getting too many requests, so the site came as a solution. Now I don't have to mail people by myself. The site will do it for me. People that are not interested in getting notification messages, just need to go in the user options page and sign-off the notification lists that they don't want to get. Anyway, the notifications are free service that is desired by many. FIY, from a little over 4000 subscribers that the site has today, only a little over 100 users signed-off to not receive notifications about new classes. Certainly some people have wondered about their privacy when they subscribe, but I am not affiliated with DoubleClick nor I am interested in exploiting the private data that people give away when they subscribe (actually only e-mail address and personal name). >repository is useless to me. PEAR will be widely mirrored as well as >being on CD-Rom distributions. It is impossible to track every user, so >there is no point trying. I was not suggesting that PEAR should keep track of downloading users. I was just letting you know how organized are the existing code repository sites today, not chaotic as you stated. >> Wouldn't it be more objective to first approach the authors of the existing >> PHP repositories and suggest the necessary improvements? I have been >> getting many improvement suggestions and as time as allowed I have been >> implementing many of the good ideas that have been passed to me. >Well, given that there is more than one, suggesting improvements to the >various ones doesn't help anything when the goal is to have a single Have you ever considered in approaching all the site maintainers and propose to merge all into one site instead of starting your own from scratch? >I am sorry that you feel we are encroaching on your territory here, but we Not at all. I just feel that PEAR sounds pretty much like a "me too" project that will duplicate most if not all that others already have available. This is a very bad thing, because unlike CPAN that helped a lot to bring the Perl community together, doing a separate repository for PHP code at this very late stage will only help to tear the PHP community apart. >are simply responding to community feedback. People screamed for database >abstraction and sessions even though various implementations were So why don't you just sanction the database abstraction layers that exist and work today and promote them in php.net instead of doing your own from scratch that will most likely take a long time until it reaches a solid state? Wouldn't it be better to help developing new drivers for at least one of the existing database abstraction layer package instead of doing it all on your own? Why not benefitting from the knowledge accumulated by those that did it before and have it matured during many months of development? Another thing that makes me wonder about PEAR is its bindings to PHP 4. The way I got it (correct me if I am wrong) PEAR modules will only work under PHP 4. If that is the case, personally I think this is a bad move. You don't need PHP 4 to have a proper code repository. I'm afraid that not everybody will move to PHP 4 any time soon. PHP 4 is still beta and will probably still be for quite a while. Then there is those that can't use anything other than PHP 3 because that is what their ISP have installed. I think it would be better to detach PEAR from the PHP development itself and make sure its modules may work under PHP 3. Another thing that makes me wonder is how the code for PEAR will be accepted. Who may contribute? How? Personally, I don't anybody should be discriminated and left out. Everybody should be able to contribute. It it is not going to be that democratic, it will most likely be a dictatorship where judgements may be influenced by personal reasons completely unrelated to the quality and usefulness of the contributed code. These are just my opinions. Given that there is no hope that PEAR will be built upon the knowledge and the content of existing code repository sites, at least I am try to be constructive in the sense that I would like to see it grow and benefit the PHP community. 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 --

« previous php.version4 (#11309) next »