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

Hello rasmus, On 02-Mar-00 02:34:41, you wrote: >> 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. >That's correct. Code in PEAR is released for others to hack on. Yet You don't need to hold code in a CVS repository to let others hack your code. >another plus as far as I am concerned. This is what Open Source is all >about. If people don't want to let others have access, they don't need to >put their code into PEAR. We won't force anybody. You and your Open Source mania. Just because you have put PHP in Open Source it doesn't mean that it is right to coerce people to do the same. The way you you are putting it Open Source follow the communist model. Follow me and tell me where it doesn't match: If you want to be part of the community, you have to give in your code or else you won't be accepted in. The community is ruled by a commitee where there is guarantee that they won't accept your work because of details that have nothing to do with its quality. The comitteed is untouchable and will last forever. All the commitee does is the right thing for the community (they assume so and don't admit otherwise). If you don't agree, and express your disagreement publically you are kind of burned, like if you were sentenced to move to Siberia or somewhere else that doesn't matter because you are already ruled out of participation in the community. If you have developed on something that is great for the community you have give in the control of its development to have it accepted. If you don't the commitee does not sanction it, which is just as bad as if your work is useless. Worst, at any time the commitee may put in efforts to duplicate your work instead of adopting it, making your work irrelevant. Meanwhile there is lot of propaganda to push the advantages of Open Source where you are free to change the code, but in reality if your contributions are not accepted it is just as bad as you could not change the code because it is hard to keep patching the original code without breaking it in every new release. Once I read an article, I think about Linux, about how Open Source soon get to be a dictatorship ruled by the mentor where only the closest friends that agree with almost everything that the mentor rules are allowed to participate. Certainly I don't mean to offend anybody here, but it is amazing how Open Source projects resemble communism, being a good or a bad thing. Fortunately, there are exception. I am glad that Zeev and Andi decided to move in for a professional (paid) development of the Zend engine. PHP needs that badly to get serious recognition and attract much more professional developers. PHP suffers a lot of the lack of recognition because there isn't much people with financial motivation to dedicate full time to professional components that need to be advertised and marketed to get proper recognition in the media. This requires more a capitalist attitude that shocks frontally with the tendentially communist attitude of the Open Source evangelists. >> 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. >This isn't a question of taking over the development, but rather one of >opening up the development to the PHP community as a whole. Nonsense, every developer may keep his own CVS repository for his code and still give it away. He may open CVS accounts for other contributors if he wants. That doesn't have to happen in the main PHP repository. You are sounding too greedy by wanting to get control of the development of the stuff that may be accepted for development in PEAR. That it is an idea as silly as if Linus wanted that all Linux programs be kept under Linux main CVS repository. Get real, it won't work. >> 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? >We have thought about this plenty, and the version tags are not much of an >issue. These are kept in CVS itself. The ones you see in actual code >files are optional and just informative. They have nothing to do with the >cvs process itself. They are a problem because once you checkout the commited files, the original CVS tags will be replaced by the new repository tags. According to the CVS manual, there is no way to selectively turn off keyword substituition. >> Nah, I don't think putting contributions in the CVS respository is a good >> idea to start with. >Not sure why you are so hung up on this point. Tracking changes is never Because if you distribute the original code with CVS tags replaced you will be changing important information like the original version number, so if somebody complaints of a bug in some version that you distribute, there is no way to track back the original version number. >a bad thing, and code can live in 2 trees rather easily. There is also no >real requirement to have all PEAR modules live in the PHP code base. You >could for example make all your classes PEAR compatible and distribute >them separately with a simple install script that sticks them into the >right place so people can do a 'use blah'. This stuff is making your life >easier, not harder. I really don't understand what you are bickering >about. This is good. What I don't want is to have to give up the control of the development of my code to have it accepted in PHP code base. >> 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?!? >Yup I guess you don't want the code in first place. It doesn't make much sense to complaint about something you are not interested. You are not helping anybody. >> 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? >You are getting completely silly here. Like I said in my original >message. PEAR is intended to be distributed widely via many different >mediums. There is no way to track everyone who gets the code >anyway. Enforcing such a system means that you can't include it in any of >the Linux distributions or on ftp.cdrom.com, *.php.net, etc. Bad idea. Nobody is preventing people that downloads the code from my repository to redistribute it elsewhere. Allowing that that's up to each author that uploads. In my repository people may even uploaded shareware code or even commercial demo code. I am not forcing people to give their stuff for free. >> 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? >Yup, I did. As far as I recall you were one of the ones not interested in As far as I can recall I never got any merge proposal. >this because you had your own ideas on how to do it. That's fine, we >happen to have our own ideas of how it should be done as well. PX was the >first. You obviously decided to start your own instead of contributing >to PX as well. Why was this? It was clearly explained. I want to know who downloads my code. Once the system collects that information, it will be able to provide a service that PX could not provide the way it was: notifying the users about new versions. I don't want to know exactly who are the users that download my code. I just would like to avoid situations where people complaint about bugs that existed in older versions because they were not warned about new fixes. Unlike what you said, once I contributed to PX with several classes of mine. There is one particular class for accessing POP3 servers (a top downloaded component in my site) that I repeatdly get complaints about a very old because that version was made available in PX. Now I redirect people to get the version from my site instead and they will always be warned about the most upto date version available, unless they don't want to. I missed this notification facility in PX and asked David Sklar to have it implemented. He refused the idea saying that it was too intrusive. I suggested that it should be enabled for components that the respective authors explicitly ask for that kind of tracking. I didn't want to have it that way either, so fine I did my own code repository and I am glad I did it because I could no longer keep track of the users of my classes in my address book. My top downloaded component (a forms generation and validation class) has over a thousand registered downloaders. Sometime ago I fixed a problem with syntax that was no longer being tolerated in PHP 4. It would be crazy if I had to keep an address book with the addresses of all those users and have too mail all of them to let them know about the fixes and then handle the new version distribution myself. If you want to stay stubborn and not admit that this is a good service and it is nice to have a site that provides this and much more for free, fine, I don't have a problem with that. But now you can't tell me you don't understand why it turned out to be that way and you don't see the need for that. >> 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. >Not at all, it will be a place to put large and mature packages. A lot of >the stuff in PX is not of the caliber that would end up in PEAR. I know >because I wrote a bunch of those PX code snippits. If it is going to be a place where contributors have to give in the control of the development of its code, forget it, I am not interested to contribute and I suspect that many other potential contributors won't be interested. I need to keep control of the code that I develop because I have a day job like many of us where I am responsible for the code that I develop. I just can't let it go have others come with arbitrary ideas that compromise the code in such way that it is no longer usable for my work. >> 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. >You are the only person who has expressed any such sentiment. Everybody >else has been quite positive about it. Your idea is different from doing a CPAN for PHP. I have just sensed that and I am expressing why and with what I disagree. Just because others don't express themselves that doesn't mean others agree. If want to believe that the sky is always blue that is your problem, because if you pay attention sometime the sky becomes gray. >> 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? >Because they are all different. Which one would be sanctioned? Stig is >taking good ideas from the various different ones. Why not stop wasting time and evaluate all to determine which one is worthy be sanctioned and cooperate in it's development instead of doing your own from scratch? From my experience it will take a long time until a good database abstraction layer becomes mature enough to attend the differences between different DBMS. PHP needed a database abstraction layer for yesterday, but going your way it will be very long months until you get something properly matured. >> 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? >We are. You are not. You are just peeking into what exists. That is pretty much like an architect that goes to Egypt to visit the pyramids and just by doing that it feels capable of doing something like that on his own. There are many enigmas about the construction of pyramids. If only it was possible to talk to the original builders, a lot could be learned instead of doing your own way just by looking. >> 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. >Well, like you said yourself, there are plenty of code repositories >catering to PHP 3. There are features in PHP 4 that make PEAR cleaner and >easier to do at this point. That doesn't mean that PEAR modules couldn't >necessarily be built to also work with PHP 3, but we have to start >somewhere. Why not start with what most people have installed: 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. >Anybody may contribute. You are insinuating that there is currently >discrimination going on. If you are going to control which may or not be accepted, somebody will inevitably be left out. I am not insinuating that somebody will be discriminated personally. I am just saying that censoring before publishing is not very constructive. >> 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. >Given that the code in these repositories is presumably open source, any >and all of it could eventually be incorporated into PEAR, so I have no >idea how you can make this statement. Free is different form Open Source. Only you want to force people to turn their code that may be available for free into Open Source. 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 --