php-windows Digest 19 Feb 2004 07:58:34 -0000 Issue 2129
Topics (messages 22901 through 22908):
Re: Working with Base64 data
22901 by: hubo
22904 by: Justin Patrin
Re: Emailing via mail(), secondary servers
22902 by: Justin Patrin
22903 by: Manuel Lemos
22905 by: Justin Patrin
22906 by: Ignatius Reilly
22907 by: Manuel Lemos
22908 by: Sven Schnitzke
Administrivia:
To subscribe to the digest, e-mail:
[EMAIL PROTECTED]
To unsubscribe from the digest, e-mail:
[EMAIL PROTECTED]
To post to the list, e-mail:
[EMAIL PROTECTED]
----------------------------------------------------------------------
--- Begin Message ---
>
> When I attempt to view the generated test.jpg in a browser, it is unable
to
> display. Same with photoshop and the windows built-in pic viewer.
> I know that the base64 data is not corrupted, since I can get it to
display
> properly in netscape with the following code:
>
> echo '<img src="data:image/jpeg;base64,'.$image_data.' ">';
>
>
> Unfortunately, I'm tied to IE. Has anyone run into a problem like this
> before?
For IE it is just (I'm using PHP 4.3.1):
echo base64_decode($image_data);
>
> Thanks!
> Steve
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hubo wrote:
When I attempt to view the generated test.jpg in a browser, it is unable
to
display. Same with photoshop and the windows built-in pic viewer.
I know that the base64 data is not corrupted, since I can get it to
display
properly in netscape with the following code:
echo '<img src="data:image/jpeg;base64,'.$image_data.' ">';
Unfortunately, I'm tied to IE. Has anyone run into a problem like this
before?
For IE it is just (I'm using PHP 4.3.1):
echo base64_decode($image_data);
Thanks!
Steve
--
PHP Windows Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
You may want to try adding a header call:
header('Content-Type: image/jpeg');
--
--
paperCrane <Justin Patrin>
--- End Message ---
--- Begin Message ---
Manuel Lemos wrote:
Hello,
On 02/18/2004 02:15 PM, B.A.T. Svensson wrote:
The main point of requiring a valid address has nothing to
do with sending you spam, but rather to make it difficult
for some authors to boost their top download ranking
positions by creating many accounts and download their own
packages. That is explained in the why page.
And that's of course what indvidual with low moral will do when
If you study a little about the human nature you will realize that tehre
would be people capable of doing that and much worse. If you just think
of people with great needs to satisfy their egos at the cost of getting
exposure to their names it is not hard to understand. It is not wrong to
desire to obtain recognition. What is wrong is to commit fraud to
obtain undeserved recognition.
Of course, this is what happens when you have "top" sites. Any "top"
site you look at has cheating in it. IMHO, you shouldn't be using the
"most downloaded" thing as that's real easy to fix.
So, you have an idea, this is the hall of fame page that provides
exposure to those that are top ranked:
http://www.phpclasses.org/browse/top/top.html
given the chanse. However my first remark (a time ago) was not
ment to spawn a oral war, but suggest reason why people would
like to select this or that package. Sometimes those reason are
not founded in technical motivated arguments, but those of
confidense and easniess. Easiness in the sence that one tend to
stick to what one already know and has developed skills with.
Sure, but when somebody does not know, people tend to follow advice or
hints provided by information based on the opinions of a significant
number of people. That is why in the PHP Classes site there charts based
on statistics collected from things like the classes that were
downloaded and rated by many users.
--
--
paperCrane <Justin Patrin>
--- End Message ---
--- Begin Message ---
Hello,
On 02/18/2004 06:40 PM, Justin Patrin wrote:
The main point of requiring a valid address has nothing to
do with sending you spam, but rather to make it difficult
for some authors to boost their top download ranking
positions by creating many accounts and download their own
packages. That is explained in the why page.
And that's of course what indvidual with low moral will do when
If you study a little about the human nature you will realize that
tehre would be people capable of doing that and much worse. If you
just think of people with great needs to satisfy their egos at the
cost of getting exposure to their names it is not hard to understand.
It is not wrong to desire to obtain recognition. What is wrong is to
commit fraud to obtain undeserved recognition.
Of course, this is what happens when you have "top" sites. Any "top"
site you look at has cheating in it. IMHO, you shouldn't be using the
"most downloaded" thing as that's real easy to fix.
Definetely you are not very skilled in addressing the needs of
communities of capable individuals.
I am not going to bother to explain why, but the existence of that top
is one of the reasons that motivates so many developers to contribute to
the PHP Classes site. The fact that only downloads done by authenticated
users count for the tops is the one of the reasons why most developers
that contribute to the site do not lift the login requirement to download.
--
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
--- End Message ---
--- Begin Message ---
Manuel Lemos wrote:
Hello,
On 02/18/2004 06:40 PM, Justin Patrin wrote:
The main point of requiring a valid address has nothing to
do with sending you spam, but rather to make it difficult
for some authors to boost their top download ranking
positions by creating many accounts and download their own
packages. That is explained in the why page.
And that's of course what indvidual with low moral will do when
If you study a little about the human nature you will realize that
tehre would be people capable of doing that and much worse. If you
just think of people with great needs to satisfy their egos at the
cost of getting exposure to their names it is not hard to understand.
It is not wrong to desire to obtain recognition. What is wrong is to
commit fraud to obtain undeserved recognition.
Of course, this is what happens when you have "top" sites. Any "top"
site you look at has cheating in it. IMHO, you shouldn't be using the
"most downloaded" thing as that's real easy to fix.
Definetely you are not very skilled in addressing the needs of
communities of capable individuals.
Why do you insist on simply saying I know nothing. Why not discuss or
explain rather than make character attacks? You still have not given me
any concrete reasons for anything you say.
I am not going to bother to explain why, but the existence of that top
is one of the reasons that motivates so many developers to contribute to
the PHP Classes site. The fact that only downloads done by authenticated
users count for the tops is the one of the reasons why most developers
that contribute to the site do not lift the login requirement to download.
--
paperCrane <Justin Patrin>
--- End Message ---
--- Begin Message ---
Although this conversation has by now undoubtedly accrued to human
knowledge, there may be other more suitable forums where to pursue it.
Ignatius
_________________________
----- Original Message -----
From: "Justin Patrin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, February 18, 2004 23:32
Subject: Re: [PHP-WIN] Re: Emailing via mail(), secondary servers
> Manuel Lemos wrote:
>
> > Hello,
> >
> > On 02/18/2004 06:40 PM, Justin Patrin wrote:
> >
> >>>>> The main point of requiring a valid address has nothing to
> >>>>> do with sending you spam, but rather to make it difficult
> >>>>> for some authors to boost their top download ranking
> >>>>> positions by creating many accounts and download their own
> >>>>> packages. That is explained in the why page.
> >>>>
> >>>>
> >>>> And that's of course what indvidual with low moral will do when
> >>>
> >>>
> >>> If you study a little about the human nature you will realize that
> >>> tehre would be people capable of doing that and much worse. If you
> >>> just think of people with great needs to satisfy their egos at the
> >>> cost of getting exposure to their names it is not hard to understand.
> >>> It is not wrong to desire to obtain recognition. What is wrong is to
> >>> commit fraud to obtain undeserved recognition.
> >>
> >>
> >>
> >> Of course, this is what happens when you have "top" sites. Any "top"
> >> site you look at has cheating in it. IMHO, you shouldn't be using the
> >> "most downloaded" thing as that's real easy to fix.
> >
> >
> > Definetely you are not very skilled in addressing the needs of
> > communities of capable individuals.
> >
>
> Why do you insist on simply saying I know nothing. Why not discuss or
> explain rather than make character attacks? You still have not given me
> any concrete reasons for anything you say.
>
> > I am not going to bother to explain why, but the existence of that top
> > is one of the reasons that motivates so many developers to contribute to
> > the PHP Classes site. The fact that only downloads done by authenticated
> > users count for the tops is the one of the reasons why most developers
> > that contribute to the site do not lift the login requirement to
download.
> >
>
> --
> paperCrane <Justin Patrin>
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--- End Message ---
--- Begin Message ---
Hello,
On 02/18/2004 02:09 AM, Justin Patrin wrote:
However, I am more interested in legitimate users that download and
try the code. This helps me test my code more intensively and iron
any bugs or limitations much faster. I do not even wish or expect
people to thank me. As long as they test the code and report any
problems, or do not report anything because it is all right for
them, that is fine for me.
I agree fully. Testing and giving back is a major reason for putting
my software out there. This is why I use PEAR. There is a large group
of both developers and users who actively work together to make the
packages better. I also like the standardization and use of high
level programming concepts, such as seperation of functionality and
re-use of code.
As much as this thread was not about PEAR and PHP Classes, you seem to
enjoy keep bringing that subject up. You sound like a snake oil
salesman, always trying to push PEAR as the best place in the world to
publish author classes, in typical attack to PHP Classes site as if it
is a great threat to your existence.
The truth is that many authors will always refuse to publish their
classes in PEAR for reasons that have nothing to with the PHP Classes
site.
Many authors, including myself, have tried to contribute to PEAR but
then there were a few individuals that were set to make it hard or
even impossible to do it, usually for reasons of arguable logic. It
seems that there is usually a small feud formed by a few individuals
that are not interested to let other developers have a role that may
put them in the shadow. With this protective attitude it is really
very hard to even try to contribute.
For instance the admitance of only one coding style will always be an
obstacle to motivate developers to contribute to PEAR. I even recall
until today, when Andrei Zmievski said PEAR coding style was so
ridiculous that made him cry. I guess that was the reason why Smarty
was never contributed as a PEAR package. Curiously, I read some
statistics that show that Smarty alone is a more popular PHP.net
project than the whole PEAR project.
I even proposed to allow to preserve the coding style of the original
contributor. The problem is that when people try to change coding
styles, not only they waste a lot of time doing it right, but they may
add bugs by accident where none existed. This proved to be true when
Lukas Smith ported Metabase to PEAR style. Many bugs were added in
code from Metabase that was working perfectly.
Forcing people to change styles is like making all right handed people
start writing with the left hand to be accepted. PEAR was set to be
what CPAN was to Perl but CPAN does not have such mandatory style
requirements.
CPAN is a very large and useful repository. It has amazing automation
and packaging as well as a great installer. However, you're missing some
points. CPAN has standards as well. You muct name your module to conform
with the namespaces already in ther system. You have to name your files
a certai way. You are encouraged to talk about your module before
submitting it. Other than that I see no written coding standards, but I
highly doubt that a badly written module will last long or be used much.
You are confusing the balls here. I said that CPAN does not have strict
coding style requirements. I never said it does not have rules. Even the
PHP Classes has rules for classes being submitted for publishing. Coding
standards is one thing more broad than just coding style.
Coding style is not a requirement because it is not possible to choose a
single style as the right one, as if the others are all wrong. Many
different coding styles can be used to make the readable and useful to
everybody. If you coerce everybody to change into a particular style as
PEAR requires, obviously many authors will be left out. Therefore, if
PEAR is not more popular, you can only blame the 'smart' PEAR rulers
that decided in favor of that.
One curious note, even PHP main code has coding standards. However
coding style is more relaxed in practice than PEAR people demands. For
instance, you will find that different parts of the PHP C source code
use tabs and others use spaces for indenting.
The Perl community is old and rife with its own politics.
I would say they are more experienced. The curious part is that a PEAR
zealot like yourself talking about Perl community politics is like
throwning stones to your neighbour roof when your own roof is made of glass.
One of the reasons why trying to submit classes to PEAR is a major
headache to many developers is precisely because of politics. The
bureacracy and the number of nay-sayers is so large, that just by
reading at the pear-dev mailing list archives, many authors that were
considering submiting their work to PEAR, simply give up as they have
better things to do than remaining in neverending discussions just to
realize that their class submissions will be boycotted anyway. This is
not my opinion, it is a fact that anybody can notice from the mailing list.
Actually, I'm not that surprised about the lack of standards surrounding
CPAN. Perl itself is a kitchen sink language, including everything under
the sun and allowing many *many* ways of doing the same thing. I myself
have never been able to figure out what to do with Perl. I've used it
and for big projects, but it doesn't scale well at all. But I'm digressing.
Perl syntax is cryptic because of its inheritance from shell scripting
languages. However I would not underestimate the knowledge and
experience of Perl developers. The fact is that many PHP people have
been porting existing Perl packages, several of them have been submitted
to PHP Classes site and PEAR. So, the coding styles used by Perl
developers was not a problem. Therefore, your complaints about Perl
sound more like fanatic attacks than valid technical criticism.
The lack of standardizaition comes with a price. If you don't enforce
any kind of standards, code can very easily have bugs and, worse, be
hard to understand and debug. I treat perl modules as compiled binaries
(as they sometimes are) because they are almost universally hard to
understand, as it most Perl.
I think you just don't know enough of Perl to comment. The fact is that
there are many Perl modules that do not have a PHP counterpart.
Until PEAR people become effectively more open minded, without any
hipocrisy and protectionism, PEAR will always suffer from the absence
of many very qualified PHP developers, making it a shadow of what PEAR
hoped to be. The reality speaks for itself. PEAR rules are not
consensual nor there seems to be great interest from PEAR people to
change that. It is all in their hands to change.
Good points, but you are missing something there. It is true that a
rigourous standard cuts out lots of developers. Even lots of talented
developers, but if you start with PEAR, it's not so hard to code for PEAR.
PEAR arrived late to the PHP scene. Therefore, I think it would have
better for PEAR popularity to adapt to the existing PHP developers
reality then to have PHP developers adapt to PEAR.
Unfortunately, since PEAR rules are intolerant, they decide to push
unflexible rules and that discouraged many developers that not only will
not use PEAR at all, but will even discourage others from using it. I am
not even talking about myself. Several proeminent PHP developers have
criticized and discouraged the use of PEAR. This is a fact, if you do
not like it, blame it on PEAR rulers.
Even if you don't start there, the standards are still a good thing.
Once you know how PEAR works, you can get any PEAR package and know how
to use it, at least in simple terms. Also, keeping the same standard
makes it much simpler to use multiple packages together and integrate
them into your application. Take the PEAR error system, for instance.
Instead of checking *every single call* for a different error sceme, I
can set a single handler to deal with them. Or, if the errors are
important, I know that every error that comes back will be in the same
format with the same information in it.
The PEAR error system is the worst example of PEAR standards. Basically
they try to emulate exceptions but in a very lame way because you can't
emulate exceptions properly if you do not have built-in support in the
language.
PEAR error system requires a 800 lines base class that is only there to
bloat classes that used it. Basically, those 800 lines only replicate
what is provided the built-in PHP functions set_error_handler and
trigger_error provide. The truth is that the PEAR error handling base
class is so bad that despite it used to be a requirement, several PEAR
classes no longer use it. So much for standards that are only there to
broken.
Again, standards are a good thing.
Sure, except when they do not get in the way of developers productivity
like some of the PEAR standards.
We know that is not accurate. Many package lack of proper
documentation. The truth is that writing proper documentation takes a
lot of time to be viable. PEAR-Doc like documentation is as good a
telegrams. Documentation is more than just a few vague words embeded
in the source. It is better than nothing but unlike what you say, many
PEAR packages do not come with sufficient documentation.
I disagree completely. Every PEAR package I have downloaded has
sufficient documentation to start using it. Like I said before, if you
can find no "documentation" all you have to do is look at the code and
you're on your way. Most PEAR classes also include regression tests
which are rigourously run before releasing a new package.
"A lie told often enough becomes the truth."
Lenin
http://www.quotationspage.com/quotes/Lenin/
You may twist the words as you like, but the truth is that most PEAR
packages do not come with real documentation. Inline PEAR-Doc comments
is not documentation, it is telegram. Some people can understand with a
few comments, but real documentation is made of text with many
explanatory full sentences and most PEAR package do not have it, which
is only natural because it takes a long time to produce real
documentation and most developers do not have the time or do not enjoy
producing documentation.
What you say below has no relation to the paragraphs that you quoted
before this.
I don't know why you're bringing up something like this. I said nothing
about your privacy policy or what you do with e-mail addresses. I didn't
bash your site. I didn't say that it wasn't helpful. I am not hostile
towards your site. If you look back in this thread, you will see that
*YOU* have been the one making this a feud. You are the one assuming
that I am attacking you. You are the one who always turns it into a
bashing contest against PEAR. I have bot bashed your site or your code
once until this latest e-mail, and I am not bashing your site (although
I could) or the ideas behind it (which are very good and laudable). All
I have done is offer an alternative and my view on why it is a good one.
I have shared my view and what I see as good about PEAR in good faith
and all you have done is complain. You have not given any concrete
reasons for your absolute hatred of PEAR. As I see it you have given
three reasons:
Are you trying to confuse people reading this thread or you are simply
clueless?
As far as I can recall, you are the one that pushed PEAR in this thread.
The initial poster presented a problem. I presented a solution that is
based on a class that for mere coincidence I made available in the PHP
Classes.
Then, in a reaction to my message you presented a solution based on a
PEAR class, that did not solve the original problem. Obviously you were
not replying to the original poster but just presenting a competing
solution. If you really wanted to reply to the original poster, you
would reply to his message, not to my reply.
Then I told you that your solution did not solve the original problem,
but then you insisted with statements that just confirmed that you did
not understand the original message, which is natural because your main
concern is to present a competing PEAR solution to my solution that just
for a coincidence is available in the PHP Classes site.
From then on you started a PEAR propaganda speech that has nothing to
do with the topic. So who is trying to attack who here?
The way I see it, if you were really concerned in providing a real
solution to the original poster, you could have ignored my participation
in this thread and just replied to the original poster message. Since
you didn't, it is obvious to me that you have an obcessive compulsion to
provide competing messages to mine, especially when I present solutions
based on classes that I make available in the PHP Classes site.
If my memory does not fail, this is at least the third thread that you
make this act of pushing PEAR as an alternative to classes made
available in the PHP Classes site.
As to your silly claims of hatred towards PEAR, that only shows that you
are completely out of the loop. You may look here to start getting a clue:
http://www.phpclasses.org/PEAR
If I really hated PEAR as you claim, would I allow publishing PEAR based
classes in the PHP Classes site?
Would I list and review PEAR books in the PHP Classes site?
http://www.phpclasses.org/reviews/id/1411603613.html
The author of this book wrote me before the book it was published and
asked me to list and review the book. The author told me that he wrote
the book because PEAR project is not very well known and he thought that
publishing this book would help PEAR. If I hated PEAR as you say,
would I agree to list the book and publish a review?
Now, pay close attention to this PEAR site page.
http://pear.php.net/package/MDB
Do you know why my name is listed in this page. I did not ask to list my
name. This PEAR package is based on another package that I developed and
has over 12,000 lines of code. This PEAR package exists because I
proposed it. If I really hated PEAR as you say, would I ever propose a
PEAR package based on a large package that I developed?
Sure I criticize PEAR rules but the criticism is intentionally
constructive because it is meant to open PEAR people eyes so they
realize why PEAR is not reaching out and do something about it.
And now, for a bit of discussion about *your* code. This thread has been
a baseless bash of PEAR for far too long.
Let's go back to documentation. Hmmm, I see code documentation at all,
If you do not see it, you must not be looking in the right places.
So far I have published 27 packages in the PHP Classes site.
http://www.phpclasses.org/mlemos
But this is just a part of my published Open Source developments. Here
you may find a more complete listing:
http://freshmeat.net/~mlemos/
As you may see, these are a lot of projects. Therefore my time is
limited. So, I only invest time in producing proper documentation in
significant projects. Smaller projects come usually with well commented
examples. Just this project manual has 280K and the tutorial more 70K.
http://www.phpclasses.org/metabase
This another popular project that is throughly documented.
http://www.phpclasses.org/formsgeneration
how interesting. Sure, there are "test" scripts which are really only
examples, and those have a fair amount of comments in them, but your
code itself has none. No comments for the functions. No comments for the
Don't be ridiculous. I do not think bloating source code with comments
is the way to go. Other reputed developers think like me . Here is an
explanation from Sterling Hughes:
http://www.edwardbear.org/serendipity/archives/1174_Comments.html
My code style is verbose. I use meaningful names for variables. You can
read my code as in English. If you do not understand my PHP code, you
need to study more PHP.
arguments. A maintainer of the code would have to look at the "tests" to
know what the packages do. Sure, that's fine while you (the maintainer)
are still here, but what if you move on? How will a new guy maintain
your code? What if you're away on sabbatical and someone needs a bug
Don't be silly, I have received so many bug reports and feature request
for my code that sometimes it is hard to reply to everybody that writes
me. Many users write to send patches for my code. Only in your clueless
imagination you can assume it is otherwise.
fix? No one else can easily step in and make a change unless they are
*intimate* with your code or take the time needed to become intimate.
No one can fix any code without knowing how it works, regardless what
kind of documentation it has.
That is not what I would call good documentation.
Only you are defending that comments is good documentation. Read
Sterling comments so I do not have to repeat what I think.
Let's go further. Your code is much less robust than most PEAR modules I
have looked at. Not only do you duplicate functionality left and right,
giving a use the samer getmxrr.php file in multiple packages and making
them deal with including it themselves, your functions seem strange and
Oh, man, you really did not do your home work. That script is just an
interface to a DNS resolver class developed by another author so it
could replace GetMXRR function under Windows or on systems where that
function does not work. Since it is a small script I copy it everywhere
it is needed because I do not want people to force downloading a pile a
packages just to use a small script that comes with one of them.
I am not fan of nested dependencies like PEAR people seem to enjoy. Deep
nested dependencies is the source of software bloat because it makes
people download a pile of packages just a small functionality provided
by one of the packages but it did not need all the others that it requested.
low level. I can do what you do in your tests with a few lines of code
and a PEAR module. The functionality you give is nowhere near the the
funtionality of the similar PEAR packages and far more confusing. Not
everyone can implement everything, but in this case, I'd go with the
more usable and more fully featured package.
Yes, by the time you start using all those packages that you download,
you realize that PHP has wasted too much memory and time processing all
the code of the packages that you used, even though you have just used
just a little bit of one or few packages.
Man, you really need to learn more about software economics.
One final curious comment, while you try so hard to push PEAR and
fight PHP Classes as if they are mutually exclusive, I think you do
not know that several PEAR authors also come to the PHP Classes site
and publish their classes their. I think they understand that exposure
in two repositories is better than in just one.
Putting your code up on multiple places is great. I don't disagree with
that *OR* phpclasses at all. You just seem to think that I am. Why are
you so defensive? What are you afraid of?
I am just restoring your distorted view of the truth.
Just as reminder, this thread only turned into this discussion because
instead of replying to the original posted, you posted a competitive
reply to my own reply, just because I presented a solution that really
solved the original problem that was based on a class that for mere
coincidence is made available in the PHP Classes site.
I am sure that if I did not reply initially in this thread, you would
even have started posting because your reply was just meant to be
competitive propaganda of PEAR as alternative to my solution.
One file remark: cooperating is better than competing. If you are smart
enough you will realize what you are wasting with your competitive posts.
--
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
--- End Message ---
--- Begin Message ---
To both of you crusaders,
first of all you are by far off topic now, so please
relocate to a suitable list. And as I don't see this
quarrel get to any kind of "solution" I would like
to add my very personal unwanted comment:
Besides and above any substantial point in any
of your proceedings it may be valuable to think
about how _the other side_ (with their respective
prereqisites) may be able to _accept_ the point one
wants to make in the first place, not to speak about
an agreement (Hint: no one likes himself or any
of his ideas to be called silly or the like ...).
Try to think about what exactly you want to achieve
_yourself_ before you start reasoning about the other's
motivations.
Happy arguments,
--
Sven
> -----Ursprüngliche Nachricht-----
> Von: Manuel Lemos [SMTP:[EMAIL PROTECTED]
> Gesendet am: Donnerstag, 19. Februar 2004 01:00
> An: [EMAIL PROTECTED]
> Betreff: Re: [PHP-WIN] Re: Emailing via mail(), secondary servers
>
> Hello,
>
> On 02/18/2004 02:09 AM, Justin Patrin wrote:
> >>>> However, I am more interested in legitimate users that download and
> >>>> try the code. This helps me test my code more intensively and iron
> >>>> any bugs or limitations much faster. I do not even wish or expect
> >>>> people to thank me. As long as they test the code and report any
> >>>> problems, or do not report anything because it is all right for
> >>>> them, that is fine for me.
> >>>>
> >>>
> >>> I agree fully. Testing and giving back is a major reason for putting
> >>> my software out there. This is why I use PEAR. There is a large group
> >>> of both developers and users who actively work together to make the
> >>> packages better. I also like the standardization and use of high
> >>> level programming concepts, such as seperation of functionality and
> >>> re-use of code.
> >>
> >>
> >>
> >> As much as this thread was not about PEAR and PHP Classes, you seem to
> >> enjoy keep bringing that subject up. You sound like a snake oil
> >> salesman, always trying to push PEAR as the best place in the world to
> >> publish author classes, in typical attack to PHP Classes site as if it
> >> is a great threat to your existence.
> >>
> >> The truth is that many authors will always refuse to publish their
> >> classes in PEAR for reasons that have nothing to with the PHP Classes
> >> site.
> >>
> >> Many authors, including myself, have tried to contribute to PEAR but
> >> then there were a few individuals that were set to make it hard or
> >> even impossible to do it, usually for reasons of arguable logic. It
> >> seems that there is usually a small feud formed by a few individuals
> >> that are not interested to let other developers have a role that may
> >> put them in the shadow. With this protective attitude it is really
> >> very hard to even try to contribute.
> >>
> >> For instance the admitance of only one coding style will always be an
> >> obstacle to motivate developers to contribute to PEAR. I even recall
> >> until today, when Andrei Zmievski said PEAR coding style was so
> >> ridiculous that made him cry. I guess that was the reason why Smarty
> >> was never contributed as a PEAR package. Curiously, I read some
> >> statistics that show that Smarty alone is a more popular PHP.net
> >> project than the whole PEAR project.
> >>
> >> I even proposed to allow to preserve the coding style of the original
> >> contributor. The problem is that when people try to change coding
> >> styles, not only they waste a lot of time doing it right, but they may
> >> add bugs by accident where none existed. This proved to be true when
> >> Lukas Smith ported Metabase to PEAR style. Many bugs were added in
> >> code from Metabase that was working perfectly.
>
>
>
> >> Forcing people to change styles is like making all right handed people
> >> start writing with the left hand to be accepted. PEAR was set to be
> >> what CPAN was to Perl but CPAN does not have such mandatory style
> >> requirements.
> >>
> >
> > CPAN is a very large and useful repository. It has amazing automation
> > and packaging as well as a great installer. However, you're missing some
> > points. CPAN has standards as well. You muct name your module to conform
> > with the namespaces already in ther system. You have to name your files
> > a certai way. You are encouraged to talk about your module before
> > submitting it. Other than that I see no written coding standards, but I
> > highly doubt that a badly written module will last long or be used much.
>
> You are confusing the balls here. I said that CPAN does not have strict
> coding style requirements. I never said it does not have rules. Even the
> PHP Classes has rules for classes being submitted for publishing. Coding
> standards is one thing more broad than just coding style.
>
> Coding style is not a requirement because it is not possible to choose a
> single style as the right one, as if the others are all wrong. Many
> different coding styles can be used to make the readable and useful to
> everybody. If you coerce everybody to change into a particular style as
> PEAR requires, obviously many authors will be left out. Therefore, if
> PEAR is not more popular, you can only blame the 'smart' PEAR rulers
> that decided in favor of that.
>
> One curious note, even PHP main code has coding standards. However
> coding style is more relaxed in practice than PEAR people demands. For
> instance, you will find that different parts of the PHP C source code
> use tabs and others use spaces for indenting.
>
>
>
> > The Perl community is old and rife with its own politics.
>
> I would say they are more experienced. The curious part is that a PEAR
> zealot like yourself talking about Perl community politics is like
> throwning stones to your neighbour roof when your own roof is made of glass.
>
> One of the reasons why trying to submit classes to PEAR is a major
> headache to many developers is precisely because of politics. The
> bureacracy and the number of nay-sayers is so large, that just by
> reading at the pear-dev mailing list archives, many authors that were
> considering submiting their work to PEAR, simply give up as they have
> better things to do than remaining in neverending discussions just to
> realize that their class submissions will be boycotted anyway. This is
> not my opinion, it is a fact that anybody can notice from the mailing list.
>
>
> > Actually, I'm not that surprised about the lack of standards surrounding
> > CPAN. Perl itself is a kitchen sink language, including everything under
> > the sun and allowing many *many* ways of doing the same thing. I myself
> > have never been able to figure out what to do with Perl. I've used it
> > and for big projects, but it doesn't scale well at all. But I'm digressing.
>
> Perl syntax is cryptic because of its inheritance from shell scripting
> languages. However I would not underestimate the knowledge and
> experience of Perl developers. The fact is that many PHP people have
> been porting existing Perl packages, several of them have been submitted
> to PHP Classes site and PEAR. So, the coding styles used by Perl
> developers was not a problem. Therefore, your complaints about Perl
> sound more like fanatic attacks than valid technical criticism.
>
>
> > The lack of standardizaition comes with a price. If you don't enforce
> > any kind of standards, code can very easily have bugs and, worse, be
> > hard to understand and debug. I treat perl modules as compiled binaries
> > (as they sometimes are) because they are almost universally hard to
> > understand, as it most Perl.
>
> I think you just don't know enough of Perl to comment. The fact is that
> there are many Perl modules that do not have a PHP counterpart.
>
>
> >> Until PEAR people become effectively more open minded, without any
> >> hipocrisy and protectionism, PEAR will always suffer from the absence
> >> of many very qualified PHP developers, making it a shadow of what PEAR
> >> hoped to be. The reality speaks for itself. PEAR rules are not
> >> consensual nor there seems to be great interest from PEAR people to
> >> change that. It is all in their hands to change.
> >
> >
> > Good points, but you are missing something there. It is true that a
> > rigourous standard cuts out lots of developers. Even lots of talented
> > developers, but if you start with PEAR, it's not so hard to code for PEAR.
>
> PEAR arrived late to the PHP scene. Therefore, I think it would have
> better for PEAR popularity to adapt to the existing PHP developers
> reality then to have PHP developers adapt to PEAR.
>
> Unfortunately, since PEAR rules are intolerant, they decide to push
> unflexible rules and that discouraged many developers that not only will
> not use PEAR at all, but will even discourage others from using it. I am
> not even talking about myself. Several proeminent PHP developers have
> criticized and discouraged the use of PEAR. This is a fact, if you do
> not like it, blame it on PEAR rulers.
>
>
> > Even if you don't start there, the standards are still a good thing.
> > Once you know how PEAR works, you can get any PEAR package and know how
> > to use it, at least in simple terms. Also, keeping the same standard
> > makes it much simpler to use multiple packages together and integrate
> > them into your application. Take the PEAR error system, for instance.
> > Instead of checking *every single call* for a different error sceme, I
> > can set a single handler to deal with them. Or, if the errors are
> > important, I know that every error that comes back will be in the same
> > format with the same information in it.
>
> The PEAR error system is the worst example of PEAR standards. Basically
> they try to emulate exceptions but in a very lame way because you can't
> emulate exceptions properly if you do not have built-in support in the
> language.
>
> PEAR error system requires a 800 lines base class that is only there to
> bloat classes that used it. Basically, those 800 lines only replicate
> what is provided the built-in PHP functions set_error_handler and
> trigger_error provide. The truth is that the PEAR error handling base
> class is so bad that despite it used to be a requirement, several PEAR
> classes no longer use it. So much for standards that are only there to
> broken.
>
>
> > Again, standards are a good thing.
>
> Sure, except when they do not get in the way of developers productivity
> like some of the PEAR standards.
>
>
>
> >> We know that is not accurate. Many package lack of proper
> >> documentation. The truth is that writing proper documentation takes a
> >> lot of time to be viable. PEAR-Doc like documentation is as good a
> >> telegrams. Documentation is more than just a few vague words embeded
> >> in the source. It is better than nothing but unlike what you say, many
> >> PEAR packages do not come with sufficient documentation.
> >>
> >
> > I disagree completely. Every PEAR package I have downloaded has
> > sufficient documentation to start using it. Like I said before, if you
> > can find no "documentation" all you have to do is look at the code and
> > you're on your way. Most PEAR classes also include regression tests
> > which are rigourously run before releasing a new package.
>
> "A lie told often enough becomes the truth."
> Lenin
>
> http://www.quotationspage.com/quotes/Lenin/
>
> You may twist the words as you like, but the truth is that most PEAR
> packages do not come with real documentation. Inline PEAR-Doc comments
> is not documentation, it is telegram. Some people can understand with a
> few comments, but real documentation is made of text with many
> explanatory full sentences and most PEAR package do not have it, which
> is only natural because it takes a long time to produce real
> documentation and most developers do not have the time or do not enjoy
> producing documentation.
>
>
>
> What you say below has no relation to the paragraphs that you quoted
> before this.
>
> > I don't know why you're bringing up something like this. I said nothing
> > about your privacy policy or what you do with e-mail addresses. I didn't
> > bash your site. I didn't say that it wasn't helpful. I am not hostile
> > towards your site. If you look back in this thread, you will see that
> > *YOU* have been the one making this a feud. You are the one assuming
> > that I am attacking you. You are the one who always turns it into a
> > bashing contest against PEAR. I have bot bashed your site or your code
> > once until this latest e-mail, and I am not bashing your site (although
> > I could) or the ideas behind it (which are very good and laudable). All
> > I have done is offer an alternative and my view on why it is a good one.
> > I have shared my view and what I see as good about PEAR in good faith
> > and all you have done is complain. You have not given any concrete
> > reasons for your absolute hatred of PEAR. As I see it you have given
> > three reasons:
>
> Are you trying to confuse people reading this thread or you are simply
> clueless?
>
> As far as I can recall, you are the one that pushed PEAR in this thread.
>
> The initial poster presented a problem. I presented a solution that is
> based on a class that for mere coincidence I made available in the PHP
> Classes.
>
> Then, in a reaction to my message you presented a solution based on a
> PEAR class, that did not solve the original problem. Obviously you were
> not replying to the original poster but just presenting a competing
> solution. If you really wanted to reply to the original poster, you
> would reply to his message, not to my reply.
>
> Then I told you that your solution did not solve the original problem,
> but then you insisted with statements that just confirmed that you did
> not understand the original message, which is natural because your main
> concern is to present a competing PEAR solution to my solution that just
> for a coincidence is available in the PHP Classes site.
>
> From then on you started a PEAR propaganda speech that has nothing to
> do with the topic. So who is trying to attack who here?
>
> The way I see it, if you were really concerned in providing a real
> solution to the original poster, you could have ignored my participation
> in this thread and just replied to the original poster message. Since
> you didn't, it is obvious to me that you have an obcessive compulsion to
> provide competing messages to mine, especially when I present solutions
> based on classes that I make available in the PHP Classes site.
>
> If my memory does not fail, this is at least the third thread that you
> make this act of pushing PEAR as an alternative to classes made
> available in the PHP Classes site.
>
> As to your silly claims of hatred towards PEAR, that only shows that you
> are completely out of the loop. You may look here to start getting a clue:
>
> http://www.phpclasses.org/PEAR
>
> If I really hated PEAR as you claim, would I allow publishing PEAR based
> classes in the PHP Classes site?
>
>
> Would I list and review PEAR books in the PHP Classes site?
>
> http://www.phpclasses.org/reviews/id/1411603613.html
>
> The author of this book wrote me before the book it was published and
> asked me to list and review the book. The author told me that he wrote
> the book because PEAR project is not very well known and he thought that
> publishing this book would help PEAR. If I hated PEAR as you say,
> would I agree to list the book and publish a review?
>
>
> Now, pay close attention to this PEAR site page.
>
> http://pear.php.net/package/MDB
>
> Do you know why my name is listed in this page. I did not ask to list my
> name. This PEAR package is based on another package that I developed and
> has over 12,000 lines of code. This PEAR package exists because I
> proposed it. If I really hated PEAR as you say, would I ever propose a
> PEAR package based on a large package that I developed?
>
>
> Sure I criticize PEAR rules but the criticism is intentionally
> constructive because it is meant to open PEAR people eyes so they
> realize why PEAR is not reaching out and do something about it.
>
>
> > And now, for a bit of discussion about *your* code. This thread has been
> > a baseless bash of PEAR for far too long.
> >
> > Let's go back to documentation. Hmmm, I see code documentation at all,
>
> If you do not see it, you must not be looking in the right places.
>
> So far I have published 27 packages in the PHP Classes site.
>
> http://www.phpclasses.org/mlemos
>
> But this is just a part of my published Open Source developments. Here
> you may find a more complete listing:
>
> http://freshmeat.net/~mlemos/
>
> As you may see, these are a lot of projects. Therefore my time is
> limited. So, I only invest time in producing proper documentation in
> significant projects. Smaller projects come usually with well commented
> examples. Just this project manual has 280K and the tutorial more 70K.
>
> http://www.phpclasses.org/metabase
>
> This another popular project that is throughly documented.
>
> http://www.phpclasses.org/formsgeneration
>
>
>
> > how interesting. Sure, there are "test" scripts which are really only
> > examples, and those have a fair amount of comments in them, but your
> > code itself has none. No comments for the functions. No comments for the
>
> Don't be ridiculous. I do not think bloating source code with comments
> is the way to go. Other reputed developers think like me . Here is an
> explanation from Sterling Hughes:
>
> http://www.edwardbear.org/serendipity/archives/1174_Comments.html
>
> My code style is verbose. I use meaningful names for variables. You can
> read my code as in English. If you do not understand my PHP code, you
> need to study more PHP.
>
>
> > arguments. A maintainer of the code would have to look at the "tests" to
> > know what the packages do. Sure, that's fine while you (the maintainer)
> > are still here, but what if you move on? How will a new guy maintain
> > your code? What if you're away on sabbatical and someone needs a bug
>
> Don't be silly, I have received so many bug reports and feature request
> for my code that sometimes it is hard to reply to everybody that writes
> me. Many users write to send patches for my code. Only in your clueless
> imagination you can assume it is otherwise.
>
>
> > fix? No one else can easily step in and make a change unless they are
> > *intimate* with your code or take the time needed to become intimate.
>
> No one can fix any code without knowing how it works, regardless what
> kind of documentation it has.
>
>
> > That is not what I would call good documentation.
>
> Only you are defending that comments is good documentation. Read
> Sterling comments so I do not have to repeat what I think.
>
>
>
> > Let's go further. Your code is much less robust than most PEAR modules I
> > have looked at. Not only do you duplicate functionality left and right,
> > giving a use the samer getmxrr.php file in multiple packages and making
> > them deal with including it themselves, your functions seem strange and
>
> Oh, man, you really did not do your home work. That script is just an
> interface to a DNS resolver class developed by another author so it
> could replace GetMXRR function under Windows or on systems where that
> function does not work. Since it is a small script I copy it everywhere
> it is needed because I do not want people to force downloading a pile a
> packages just to use a small script that comes with one of them.
>
> I am not fan of nested dependencies like PEAR people seem to enjoy. Deep
> nested dependencies is the source of software bloat because it makes
> people download a pile of packages just a small functionality provided
> by one of the packages but it did not need all the others that it requested.
>
>
> > low level. I can do what you do in your tests with a few lines of code
> > and a PEAR module. The functionality you give is nowhere near the the
> > funtionality of the similar PEAR packages and far more confusing. Not
> > everyone can implement everything, but in this case, I'd go with the
> > more usable and more fully featured package.
>
> Yes, by the time you start using all those packages that you download,
> you realize that PHP has wasted too much memory and time processing all
> the code of the packages that you used, even though you have just used
> just a little bit of one or few packages.
>
> Man, you really need to learn more about software economics.
>
>
> >> One final curious comment, while you try so hard to push PEAR and
> >> fight PHP Classes as if they are mutually exclusive, I think you do
> >> not know that several PEAR authors also come to the PHP Classes site
> >> and publish their classes their. I think they understand that exposure
> >> in two repositories is better than in just one.
> >>
> >
> > Putting your code up on multiple places is great. I don't disagree with
> > that *OR* phpclasses at all. You just seem to think that I am. Why are
> > you so defensive? What are you afraid of?
>
> I am just restoring your distorted view of the truth.
>
> Just as reminder, this thread only turned into this discussion because
> instead of replying to the original posted, you posted a competitive
> reply to my own reply, just because I presented a solution that really
> solved the original problem that was based on a class that for mere
> coincidence is made available in the PHP Classes site.
>
> I am sure that if I did not reply initially in this thread, you would
> even have started posting because your reply was just meant to be
> competitive propaganda of PEAR as alternative to my solution.
>
> One file remark: cooperating is better than competing. If you are smart
> enough you will realize what you are wasting with your competitive posts.
>
>
> --
>
> 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
>
> --
> PHP Windows Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
--- End Message ---
