RE: Sending filing attachments using PHP

Have a look on this:

http://framework.zend.com/manual/en/zend.mail.attachments.ht ml


It seems to be easy with zend framework




-----Mensaje original-----
De: Ron Piggott (PHP) [mailto:ron.php@actsministries.org]
Enviado el: Jueves, 11 de Mayo de 2006 05:34 p.m.
Para: PHP DB
Asunto: [PHP-DB] Sending filing attachments using PHP


Does any one know how to send a file attachment using PHP?

I have been using the mail() command to send e-mail in various scripts, but
have spotted a file attachment syntax to use on the php web page.

Ron

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Sending filing attachments using PHP

Does any one know how to send a file attachment using PHP?

I have been using the mail() command to send e-mail in various scripts,
but have spotted a file attachment syntax to use on the php web page.

Ron

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Ing. Edwin Cruz wrote:
> Have a look on this:
>
> http://framework.zend.com/manual/en/zend.mail.attachments.ht ml
>
>
> It seems to be easy with zend framework

How about a way to do it without having to install a huge system wide
binary and configruation that might potentially break apache and all PHP
sites?

http://search.cpan.org/perldoc?Mail::Sender::Easy

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Ummm... dude...

Zend Framework is NOT a "system wide binary"...

besides is like way beta right now... fun to play with, sure, but
they're not really recommending it for production yet.

try phpmailer or some of the other mail classes

Ed
On May 11, 2006, at 5:57 PM, JupiterHost.Net wrote:

>
>
> Ing. Edwin Cruz wrote:
>> Have a look on this:
>> http://framework.zend.com/manual/en/zend.mail.attachments.ht ml
>> It seems to be easy with zend framework
>
> How about a way to do it without having to install a huge system
> wide binary and configruation that might potentially break apache
> and all PHP sites?
>
> http://search.cpan.org/perldoc?Mail::Sender::Easy
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

JupiterHost.Net wrote:
>
>
> Ing. Edwin Cruz wrote:
>
>> Have a look on this:
>>
>> http://framework.zend.com/manual/en/zend.mail.attachments.ht ml
>>
>>
>> It seems to be easy with zend framework
>
>
> How about a way to do it without having to install a huge system wide
> binary and configruation that might potentially break apache and all PHP
> sites?
>
> http://search.cpan.org/perldoc?Mail::Sender::Easy
>

The OP is asking for a PHP solution and you point to cpan.. Hmm.

phpmailer (phpmailer.sourceforge.net) handles everything for you.. even
if you want to roll your own, that code will give you a good starting point.

--
Postgresql & php tutorials
http://www.designmagick.com/

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

I came up with some code today. I started e-mailing myself file
attachments to see what my e-mail program did in preparing them and when
I opened the e-mails I changed the view to "show e-mail source".

The biggest challenge is the boundary that separates the e-mail message
text from the file attachment. I found this command on php.net here to
generate the boundary:

$boundary = md5(uniqid(time()));

Then it is like baking cookies --- You just fill in the pieces:

You have to include

$headers .= "Content-Type: multipart/mixed; boundary=\"". $boundary .
"\"\r\n";

in the header field of the mail() function. (It is important the
boundary has "'s around it)

Then you have to have these lines before the text of the message (I
have /html for creating an HTML based e-mail):

$message = "--" . $boundary . "
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
{blank line}
E-mail message text is here

";

and then for the file attachment headers you put in these lines:

$file_attachment_header = "--" . $boundary;
$file_attachment_header .= "Content-Disposition: attachment;
filename=finances.pdf\r\n";
$file_attachment_header .= "Content-Type: application/pdf;
name=finances.pdf\r\n";
$file_attachment_header .= "Content-Transfer-Encoding: base64\r\n";

and then you convert your file over to 64 bit encoding

$data = file_get_contents($file);
chunk_split( base64_encode($data), 68, "\n");

#you want to limit each line to a certain number of characters,
#in this example 68 so it will go through the mail server ok

Now close off the e-mail with this final boundary
$footer = "--" . $boudary . "--";

$message = $message . $file_attachment_header . $data . $footer;

#file attachments and the file attachment headers are
#really part of the e-mail message

Then you issue the command

mail($email_address, $email_subject, $message, $headers);

Ron

On Thu, 2006-05-11 at 18:33 -0400, Ron Piggott (PHP) wrote:
> Does any one know how to send a file attachment using PHP?
>
> I have been using the mail() command to send e-mail in various scripts,
> but have spotted a file attachment syntax to use on the php web page.
>
> Ron

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

Ron Piggott (PHP) wrote:
> I came up with some code today. I started e-mailing myself file
> attachments to see what my e-mail program did in preparing them and when
> I opened the e-mails I changed the view to "show e-mail source".
>
> The biggest challenge is the boundary that separates the e-mail message
> text from the file attachment. I found this command on php.net here to
> generate the boundary:

You're piping a hand crafted mime message to sendmial via mail()?

You are a glutton for pain :) (and oh yeah theres about a zillion MIME
issues you've overlooked that will come back and bite you later, gauranteed)

use a tool thats made for it:

http://search.cpan.org/perldoc?Mail::Sender::Easy

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Chris wrote:

> JupiterHost.Net wrote:
>
>>
>>
>> Ing. Edwin Cruz wrote:
>>
>>> Have a look on this:
>>>
>>> http://framework.zend.com/manual/en/zend.mail.attachments.ht ml
>>>
>>>
>>> It seems to be easy with zend framework
>>
>>
>>
>> How about a way to do it without having to install a huge system wide
>> binary and configruation that might potentially break apache and all
>> PHP sites?
>>
>> http://search.cpan.org/perldoc?Mail::Sender::Easy
>>
>
> The OP is asking for a PHP solution and you point to cpan.. Hmm.

Yep, because PHP is not usually (some say *never*) the best solution
*and* this *is* a PHP + DB list so the OP actually has nothing to do
with thei slist anyway.

> phpmailer (phpmailer.sourceforge.net) handles everything for you.. even
> if you want to roll your own, that code will give you a good starting
> point.

Right after rebuilding php and apache and breaking PHP funtionality for
everyone, just so you can send a semi complex MIME message? That is the
epitome of PHP's lameness and why I can't sit quietly by and not
recommend an easy to install and use and maintain solution.

And besides its in a non strutcutered way to maek it even more
impossible to maintain.

Look at the EXAMPLE section of that url, see how incredibly easy and
intuitive it is to sent complex emails?

And all the server admin has to do is:

perl -MCPAN -e 'install Mail::Sender::Easy;'

- no fiddling with apache
- no fiddling with the interpretet binary
- no possibility of breaking anyone's scripts


Or else you could do liek the one guy and make your own MIME message but
that is even dumber than insisting that PHP has to be used.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

Alister Bulman wrote:

> On 12/05/06, JupiterHost.Net wrote:
>
>> You're piping a hand crafted mime message to sendmial via mail()?
>>
>> You are a glutton for pain :) (and oh yeah theres about a zillion MIME
>> issues you've overlooked that will come back and bite you later,
>> gauranteed)
>>
>> use a tool thats made for it:
>> http://search.cpan.org/perldoc?Mail::Sender::Easy
>
>
> I agree - don't get bitten on the ass, but OTOH, there's already a PHP
> Mime encoder - no need to point him to a Perl library....
>
> http://pear.php.net/package/Mail_Mime

Yes there's a huge need, PHP is way to problematic and many folks don't
even realize thats its one of a hundred possible tools. Most of which
are better suited for most things.

Plus, what if you don't have Pear compiled into PHP? Now theres more
hoops, oops need zend optimizer, more hoops, oops that version doesn;t
work on that verison, more hoops. Oh yeah and you have to be root to do
all this, nice.

And that module is not a MIME tool in itself, it uses perl's MIME tools
and SMTP tools but it abstracts all of that for you so all you have to
do is make a hash that represents your mail. No knowlege of SMTP or MIME
necessary.

And you can install it as a regular user and use it yourself if need be,
what could be easier :)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Edward Vermillion wrote:

> Ummm... dude...
>
> Zend Framework is NOT a "system wide binary"...

Semantics.

The point is its more fiddling, why fiddle (and likely break something)
when you don't need to.

> besides is like way beta right now... fun to play with, sure, but
> they're not really recommending it for production yet.
>
> try phpmailer or some of the other mail classes

Getting closer, but now you better hope you have Pear or PECLsupport
compiled in, if not, more fiddling....

Or els e you have to use a php file that has some functions you can use
(in no structered or organized way, lame lame lame)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

JupiterHost.Net wrote:

> Chris wrote:
>
>> JupiterHost.Net wrote:
>>
>>> Ing. Edwin Cruz wrote:
>>>
>>>> Have a look on this:
>>>>
>>>> http://framework.zend.com/manual/en/zend.mail.attachments.ht ml
>>>>
>>>>
>>>> It seems to be easy with zend framework
>>>
>>>
>>> How about a way to do it without having to install a huge system
>>> wide binary and configruation that might potentially break apache
>>> and all PHP sites?
>>>
>>> http://search.cpan.org/perldoc?Mail::Sender::Easy
>>
>>
>> The OP is asking for a PHP solution and you point to cpan.. Hmm.
>
>
> Yep, because PHP is not usually (some say *never*) the best solution
> *and* this *is* a PHP + DB list so the OP actually has nothing to do
> with thei slist anyway.


Agreed, but the subject does say "using PHP".

>> phpmailer (phpmailer.sourceforge.net) handles everything for you..
>> even if you want to roll your own, that code will give you a good
>> starting point.
>
>
> Right after rebuilding php and apache and breaking PHP funtionality
> for everyone, just so you can send a semi complex MIME message? That
> is the epitome of PHP's lameness and why I can't sit quietly by and
> not recommend an easy to install and use and maintain solution.


Why are you rebuilding PHP and Apache? In what way does phpmailer (a
completely PHP-based solution with no external dependancies) force you
to do this and "break[ing] PHP functionality for everyone"?

> And besides its in a non strutcutered way to maek it even more
> impossible to maintain.


I assume that's a generic dig at PHP. For me, the lack of an enforced
structure makes it easier to maintain since it gives you the freedom to
put in your own structure.

I don't know you from Adam, but for whatever reason you seem to hate
PHP. I'm sure whatever it did it wasn't personal. Please do us all a
favour and unsubscribe from this list, or at the very least please stop
posting pointless and time-wasting answers.

-Stut

--
If ignorance is bliss, you must be in heaven!

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

JupiterHost.Net wrote:

> Alister Bulman wrote:
>
>> On 12/05/06, JupiterHost.Net wrote:
>>
>>> You're piping a hand crafted mime message to sendmial via mail()?
>>>
>>> You are a glutton for pain :) (and oh yeah theres about a zillion MIME
>>> issues you've overlooked that will come back and bite you later,
>>> gauranteed)
>>>
>>> use a tool thats made for it:
>>> http://search.cpan.org/perldoc?Mail::Sender::Easy
>>
>>
>> I agree - don't get bitten on the ass, but OTOH, there's already a PHP
>> Mime encoder - no need to point him to a Perl library....
>>
>> http://pear.php.net/package/Mail_Mime
>
>
> Yes there's a huge need, PHP is way to problematic and many folks
> don't even realize thats its one of a hundred possible tools. Most of
> which are better suited for most things.
>
> Plus, what if you don't have Pear compiled into PHP? Now theres more
> hoops, oops need zend optimizer, more hoops, oops that version doesn;t
> work on that verison, more hoops. Oh yeah and you have to be root to
> do all this, nice.


What planet are you on? Seriously? Because PEAR does not need to be
compiled into PHP. Zend Optimizer is no different to the optimizers
available for other scripting languages. Version mismatches are a fact
of life with all tools, deal with it. And last but not least, you do not
have to be root to do anything with PHP, or indeed Apache except to
listen on a port lower than 1024, which is true for all tools since it's
a platform limitation.

> And that module is not a MIME tool in itself, it uses perl's MIME
> tools and SMTP tools but it abstracts all of that for you so all you
> have to do is make a hash that represents your mail. No knowlege of
> SMTP or MIME necessary.
>
> And you can install it as a regular user and use it yourself if need
> be, what could be easier :)


Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is
another example of a pure-php class. It certainly does not use anything
perl related at all. I'd really like to know what makes you think it does.

Oh, and there's nothing stopping you installing any of the PEAR classes
as a regular user and using it yourself. What could be easier? Not
having to read your ignorant emails.

-Stut

--
If ignorance is bliss, you must be in heaven!

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

RE: Sending filing attachments using PHP

" Right after rebuilding php and apache and breaking PHP funtionality for
everyone, just so you can send a semi complex MIME message? That is the
epitome of PHP's lameness and why I can't sit quietly by and not
recommend an easy to install and use and maintain solution."

This command breaks Apache?
require("class.phpmailer.php");

" And besides its in a non strutcutered way to maek it even more
impossible to maintain."

Classes and Object Oriented Programming?



-----Original Message-----
From: JupiterHost.Net [mailto:mlists@jupiterhost.net]
Sent: Friday, May 12, 2006 10:10 AM
To: 'PHP DB'
Subject: Re: [PHP-DB] Sending filing attachments using PHP



Chris wrote:

> JupiterHost.Net wrote:
>
>>
>>
>> Ing. Edwin Cruz wrote:
>>
>>> Have a look on this:
>>>
>>> http://framework.zend.com/manual/en/zend.mail.attachments.ht ml
>>>
>>>
>>> It seems to be easy with zend framework
>>
>>
>>
>> How about a way to do it without having to install a huge system wide
>> binary and configruation that might potentially break apache and all
>> PHP sites?
>>
>> http://search.cpan.org/perldoc?Mail::Sender::Easy
>>
>
> The OP is asking for a PHP solution and you point to cpan.. Hmm.

Yep, because PHP is not usually (some say *never*) the best solution
*and* this *is* a PHP + DB list so the OP actually has nothing to do
with thei slist anyway.

> phpmailer (phpmailer.sourceforge.net) handles everything for you.. even
> if you want to roll your own, that code will give you a good starting
> point.

Right after rebuilding php and apache and breaking PHP funtionality for
everyone, just so you can send a semi complex MIME message? That is the
epitome of PHP's lameness and why I can't sit quietly by and not
recommend an easy to install and use and maintain solution.

And besides its in a non strutcutered way to maek it even more
impossible to maintain.

Look at the EXAMPLE section of that url, see how incredibly easy and
intuitive it is to sent complex emails?

And all the server admin has to do is:

perl -MCPAN -e 'install Mail::Sender::Easy;'

- no fiddling with apache
- no fiddling with the interpretet binary
- no possibility of breaking anyone's scripts


Or else you could do liek the one guy and make your own MIME message but
that is even dumber than insisting that PHP has to be used.

--

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Edward Vermillion wrote:
> You've made it obvious by all of your replies that you have no idea
> what you're talking about, so maybe it would be a good time to *not*
> reply and let the folks that know what they're talking about actually
> try to help people? Eh? Maybe?

a) Im speaking in generalitites of working with PHP not specifics
componentss of the technology.

b) I am trying to help :)

Good day to all, sorry if I was to ambiguouse or I've offended

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

> What planet are you on? Seriously? Because PEAR does not need to be
> compiled into PHP. Zend Optimizer is no different to the optimizers

I was referring to --with-pear, sorry "compiled" was not the right word *

> available for other scripting languages. Version mismatches are a fact

I was referring to how Zend Opt is "required" for some stuff mainly
because its necessary to offset the bloat. *

> of life with all tools, deal with it. And last but not least, you do not

And PHP tends to have a greater majority of them, have you ever managed
PHP on multiple servers? If you have you kwo exactly what I'm referring to.

> have to be root to do anything with PHP, or indeed Apache except to

I was referring to building PHP/Apache in general *

> listen on a port lower than 1024, which is true for all tools since it's
> a platform limitation.

* I'm speaking in generalitites of working with PHP not specifics
components of the technology.

>> And that module is not a MIME tool in itself, it uses perl's MIME
>> tools and SMTP tools but it abstracts all of that for you so all you
>> have to do is make a hash that represents your mail. No knowlege of
>> SMTP or MIME necessary.
>>
>> And you can install it as a regular user and use it yourself if need
>> be, what could be easier :)
>
> Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is
> another example of a pure-php class. It certainly does not use anything
> perl related at all. I'd really like to know what makes you think it does.

I never said PEAR or any specific package used Perl, I'd simply offered
a better solution that happend to be done in Perl.

> Oh, and there's nothing stopping you installing any of the PEAR classes
> as a regular user and using it yourself. What could be easier? Not
> having to read your ignorant emails.

I was outlining some of PHP faults, not getting personal which truly
*is* ignorant.

Good day to all, sorry if I was to ambiguouse or I've offended.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Dwight Altman wrote:

> " Right after rebuilding php and apache and breaking PHP funtionality for
> everyone, just so you can send a semi complex MIME message? That is the
> epitome of PHP's lameness and why I can't sit quietly by and not
> recommend an easy to install and use and maintain solution."
>
> This command breaks Apache?
> require("class.phpmailer.php");
> " And besides its in a non strutcutered way to maek it even more
> impossible to maintain."
>
> Classes and Object Oriented Programming?

Thanks Dwight, good info.

I'm speaking in generalitites of working with PHP not specifics
components of the technology.

As an example of this general clutter/bloat/mess that PHPs basic
paradigm is see:

http://tnx.nl/php

Disclaimer: Note that that url is a comparison of Perl to PHP, which is
not what I'm saying in all this mess. Just look at each point of PHP and
if you don't see whay iots so bad look at how Perl does it and hopefully
it will make more clear where I'm coming from for at least part of my
argument (the deve part) that PHP has many negatives things about it
that are either not an issue in other langauges or are not nearly as
pronounced or common to run up against.

I'm very sorry if this makes some uncomfortable but note that I'm
pointing out downfalls of PHP, a "thing", I am not getting personal and
would appreciate the same courtesy. (which Dwight and Edward have done,
thanks ;p)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

Let me start by apologising if my posts came across as personal. Check
the archives for my posts, primarily on php-general and you will see
that I have a very sarcastic personality. No offence was meant or is
meant by what follows.

JupiterHost.Net wrote:
>> What planet are you on? Seriously? Because PEAR does not need to be
>> compiled into PHP. Zend Optimizer is no different to the optimizers
>
> I was referring to --with-pear, sorry "compiled" was not the right word *

I'm not familiar with the switch you are referring to. If you look into
PEAR a bit closer you will find that it is simply a package of classes.
It does not need any changes to your PHP binary for it to work correctly.

>> available for other scripting languages. Version mismatches are a fact
>
> I was referring to how Zend Opt is "required" for some stuff mainly
> because its necessary to offset the bloat. *

I'm not sure what gives you the impression that Zend Optimizer is
"required" for anything. ZO is a system for pre-compiling PHP code to
bytecodes such that the PHP source files do not need to be interpreted
each time they are run. While it is true that some commercial software
written in PHP is encoded and requires ZO, but this is a choice of that
particular developer and is not attributable to PHP as a language or as
a technology.

>> of life with all tools, deal with it. And last but not least, you do not
>
> And PHP tends to have a greater majority of them, have you ever managed
> PHP on multiple servers? If you have you kwo exactly what I'm referring to.

I maintain 13 servers in total, each of them have PHP installed, and
I've never had a problem with version issues. And I have to say that in
my experience other tools have more problems with this. Perl used to be
a nightmare for us until we rewrote the scripts we had in PHP. I'm not
blaming PHP for this, I'm just trying to point out that problems related
to version mismatches are usually related to the administrators
understanding of that particular package. For me that means Perl caused
me more issues than PHP because I know PHP better.

>> have to be root to do anything with PHP, or indeed Apache except to
>
> I was referring to building PHP/Apache in general *

You do not need to be root to build PHP or Apache, or in fact anything
else, so I'm not sure where you're getting that requirement from.

>> listen on a port lower than 1024, which is true for all tools since
>> it's a platform limitation.
>
> * I'm speaking in generalitites of working with PHP not specifics
> components of the technology.

In that case I would point out that your personal experiences with PHP
are not necessarily a reflection on PHP. I hope you don't take offense
at that but I know a huge number of developers and sysadmins who are
more than happy with working with PHP, and nearly all of them have been
through the process of trying the alternatives before landing on PHP as
the right solution for them.

>>> And that module is not a MIME tool in itself, it uses perl's MIME
>>> tools and SMTP tools but it abstracts all of that for you so all you
>>> have to do is make a hash that represents your mail. No knowlege of
>>> SMTP or MIME necessary.
>>>
>>> And you can install it as a regular user and use it yourself if need
>>> be, what could be easier :)
>>
>> Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime
>> is another example of a pure-php class. It certainly does not use
>> anything perl related at all. I'd really like to know what makes you
>> think it does.
>
> I never said PEAR or any specific package used Perl, I'd simply offered
> a better solution that happend to be done in Perl.

Quoting your original post... "it uses perl's MIME tools and SMTP
tools". How is that not saying "PEAR or any specific package used Perl"?

Your solution was not "better" given the context of the question.
Specifically that the question was asking about doing something in PHP
and was asked on the PHP list meaning it's not a great leap to assume
the guy need a solution in PHP.

>> Oh, and there's nothing stopping you installing any of the PEAR
>> classes as a regular user and using it yourself. What could be easier?
>> Not having to read your ignorant emails.
>
> I was outlining some of PHP faults, not getting personal which truly
> *is* ignorant.

I hope you understand that I wasn't getting personal, but you must
accept that your answers so far have suggested that you don't actually
know much about what you are talking about.

> Good day to all, sorry if I was to ambiguouse or I've offended.

Feel free to ignore the rest of this post, which I hope you'll take in
the spirit it is meant, but please answer me this. What has PHP done to
you? Why are you so anti-PHP? And specifically why are you on a PHP list
suggesting people use a different technology?

-Stut

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

------=_Part_30147_23405693.1147460437745
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

2006/5/12, JupiterHost.Net :
>
>
>
> Dwight Altman wrote:
>
> > " Right after rebuilding php and apache and breaking PHP funtionality
> for
> > everyone, just so you can send a semi complex MIME message? That is the
> > epitome of PHP's lameness and why I can't sit quietly by and not
> > recommend an easy to install and use and maintain solution."
> >
> > This command breaks Apache?
> > require("class.phpmailer.php");
> > " And besides its in a non strutcutered way to maek it even more
> > impossible to maintain."
> >
> > Classes and Object Oriented Programming?
>
> Thanks Dwight, good info.
>
> I'm speaking in generalitites of working with PHP not specifics
> components of the technology.
>
> As an example of this general clutter/bloat/mess that PHPs basic
> paradigm is see:
>
> http://tnx.nl/php
>
> Disclaimer: Note that that url is a comparison of Perl to PHP, which is
> not what I'm saying in all this mess. Just look at each point of PHP and
> if you don't see whay iots so bad look at how Perl does it and hopefully
> it will make more clear where I'm coming from for at least part of my
> argument (the deve part) that PHP has many negatives things about it
> that are either not an issue in other langauges or are not nearly as
> pronounced or common to run up against.
>
> I'm very sorry if this makes some uncomfortable but note that I'm
> pointing out downfalls of PHP, a "thing", I am not getting personal and
> would appreciate the same courtesy. (which Dwight and Edward have done,
> thanks ;p)
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

It's a fact that I can't deny any of the bad points you have exposed about
PHP. I even agree with you that most of this problems are really awful and
it's pointless to hide them. But the fact that PHP is by preference the
language for developing small and middle web solutions aimed to be economic
and rapidly developed is also undeniable. All languages have their pros and
cons, and trying to compare them outside of the context of the target marke=
t
is pointless. It just happens that PHP pros fit better the desires of the
web solutions market, and they also don't care much about current PHP cons.

Anyway, this market is evolving and its needs are changing, so it's normal
for developers to try and anticipate future development needs and try to
make PHP fit into other philosophies, methodologies or technologies it was
not designed to work with, and everyone who has tried this (including me)
have started to hate PHP in a certain way. But that's all there is to it, I
hate not having a proper application framework, I hate not having
namespaces, I hate the overhead of working with OOP, I hate magic quotes,
but I still use PHP because it is still the most appropiate development
enviroment for a small or middle sized web solution.

I'm guessing this part, but I think you think alike and that's the reason
you're still on this list and trying to make a point out of your bad
experiences with PHP. We can still hope that this problems will be solved
without harming the spirit of PHP in future versions or future enhacements,
and that our needs will be somehow be heard. If not, well they will realize
soon that current trends are leading to a different kind of solutions (not
that utopic Web2.0 but a more realistic Web1.5).

Thanks for sharing your opinion and concerns, I really appreciate them.

------=_Part_30147_23405693.1147460437745--

Re: Sending filing attachments using PHP

------=_Part_30567_20976606.1147462132532
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

2006/5/12, Martin Alterisio :
>
> ...

I hate not having a proper application framework,
>
....
>


Sorry, there is a mistake there. I meant to say that I hate not having an
application server, although I also think currently available framework are
just not the way to go. They are too big and produce too much overhead.

------=_Part_30567_20976606.1147462132532--

Re: Sending filing attachments using PHP

> It's a fact that I can't deny any of the bad points you have exposed about
> PHP. I even agree with you that most of this problems are really awful and
> it's pointless to hide them. But the fact that PHP is by preference the
> language for developing small and middle web solutions aimed to be economic
> and rapidly developed is also undeniable. All languages have their pros and
> cons, and trying to compare them outside of the context of the target
> market
> is pointless. It just happens that PHP pros fit better the desires of the
> web solutions market, and they also don't care much about current PHP cons.

Most people aren't aware of the cons, thats my point :)

For example:
If Mr. big wig was aware that phpBB has a history if being uber
hackable and even being used in a rootkit scheme a time or two he'd not
choose PHP. But its shiny so he says "go with that it looks nice".

That is how its popularity has grown, ignorance of the facts.

> Anyway, this market is evolving and its needs are changing, so it's normal
> for developers to try and anticipate future development needs and try to
> make PHP fit into other philosophies, methodologies or technologies it was
> not designed to work with, and everyone who has tried this (including me)
> have started to hate PHP in a certain way. But that's all there is to it, I
> hate not having a proper application framework, I hate not having
> namespaces, I hate the overhead of working with OOP, I hate magic quotes,
> but I still use PHP because it is still the most appropiate development
> enviroment for a small or middle sized web solution.

Why not use Perl, it has all the "pros" but does not have the cons :)

In fact, I use it for several high volumn websites:
- with persistent database connections and persistently running
instances of the script
(which is the *only* positive PHP has, except it means running PHP
as "nobody" and with really really bad permissions)
- without doing *anything* with apache
- works with SuExec so it runs as the user so the permissions can be
700 and config files 600 - try that with PHP without days of fiddling
and breaking stuff and finally giving up ;)

Now you have the only "benefit" of PHP (but better) without *any* of its
downside.

> I'm guessing this part, but I think you think alike and that's the reason
> you're still on this list and trying to make a point out of your bad
> experiences with PHP. We can still hope that this problems will be solved

It won't, for "backwards compatibility" they'll have to keep the cobbled
up mess. Or else make it new from scratch and remove the crap, but in
that case itd be a brand new langauge and would have all the problems
inherent with that :)

> Thanks for sharing your opinion and concerns, I really appreciate them.

My pleasure, I've been managing hundreds of servers for nearly a decade
and PHP has always had seriouse drawbacks. I've really honestly tried to
make a go of it but its just to much overhead to be worth it, IMHO :)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Then Please, stop posting here...it just is not constructive...

If you have these issues that need addressing to make it a better langauge,
then talk to the nice people at Zend and get invovled in making things
better.

All the rest if useless diatribe.

Regards

Bastien


>From: "JupiterHost.Net"
>To: PHP DB
>Subject: Re: [PHP-DB] Sending filing attachments using PHP
>Date: Fri, 12 May 2006 15:39:44 -0500
>
>
>>It's a fact that I can't deny any of the bad points you have exposed about
>>PHP. I even agree with you that most of this problems are really awful and
>>it's pointless to hide them. But the fact that PHP is by preference the
>>language for developing small and middle web solutions aimed to be
>>economic
>>and rapidly developed is also undeniable. All languages have their pros
>>and
>>cons, and trying to compare them outside of the context of the target
>>market
>>is pointless. It just happens that PHP pros fit better the desires of the
>>web solutions market, and they also don't care much about current PHP
>>cons.
>
>Most people aren't aware of the cons, thats my point :)
>
>For example:
> If Mr. big wig was aware that phpBB has a history if being uber hackable
>and even being used in a rootkit scheme a time or two he'd not choose PHP.
>But its shiny so he says "go with that it looks nice".
>
>That is how its popularity has grown, ignorance of the facts.
>
>>Anyway, this market is evolving and its needs are changing, so it's normal
>>for developers to try and anticipate future development needs and try to
>>make PHP fit into other philosophies, methodologies or technologies it was
>>not designed to work with, and everyone who has tried this (including me)
>>have started to hate PHP in a certain way. But that's all there is to it,
>>I
>>hate not having a proper application framework, I hate not having
>>namespaces, I hate the overhead of working with OOP, I hate magic quotes,
>>but I still use PHP because it is still the most appropiate development
>>enviroment for a small or middle sized web solution.
>
>Why not use Perl, it has all the "pros" but does not have the cons :)
>
>In fact, I use it for several high volumn websites:
> - with persistent database connections and persistently running instances
>of the script
> (which is the *only* positive PHP has, except it means running PHP as
>"nobody" and with really really bad permissions)
> - without doing *anything* with apache
> - works with SuExec so it runs as the user so the permissions can be 700
>and config files 600 - try that with PHP without days of fiddling and
>breaking stuff and finally giving up ;)
>
>Now you have the only "benefit" of PHP (but better) without *any* of its
>downside.
>
>>I'm guessing this part, but I think you think alike and that's the reason
>>you're still on this list and trying to make a point out of your bad
>>experiences with PHP. We can still hope that this problems will be solved
>
>It won't, for "backwards compatibility" they'll have to keep the cobbled up
>mess. Or else make it new from scratch and remove the crap, but in that
>case itd be a brand new langauge and would have all the problems inherent
>with that :)
>
> > Thanks for sharing your opinion and concerns, I really appreciate them.
>
>My pleasure, I've been managing hundreds of servers for nearly a decade and
>PHP has always had seriouse drawbacks. I've really honestly tried to make a
>go of it but its just to much overhead to be worth it, IMHO :)
>
>--
>PHP Database Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

Stut wrote:

> Let me start by apologising if my posts came across as personal. Check

If? How else can "What could be easier? Not having to read your ignorant
emails." be taken?

No worries though I understand, thanks :)

>>> What planet are you on? Seriously? Because PEAR does not need to be
>>> compiled into PHP. Zend Optimizer is no different to the optimizers
>>
>>
>> I was referring to --with-pear, sorry "compiled" was not the right word *
>
> I'm not familiar with the switch you are referring to. If you look into

in PHP source:
../configure --help

> PEAR a bit closer you will find that it is simply a package of classes.
> It does not need any changes to your PHP binary for it to work correctly.
>
>>> available for other scripting languages. Version mismatches are a fact
>>
>>
>> I was referring to how Zend Opt is "required" for some stuff mainly
>> because its necessary to offset the bloat. *
>
>
> I'm not sure what gives you the impression that Zend Optimizer is
> "required" for anything. ZO is a system for pre-compiling PHP code to

If a PHP system has been "Optimized" then it requires ZO. Most admins
need to have ZO since at least one of theri users will want to use sucha
PHP system.

> bytecodes such that the PHP source files do not need to be interpreted
> each time they are run. While it is true that some commercial software
> written in PHP is encoded and requires ZO, but this is a choice of that
> particular developer and is not attributable to PHP as a language or as
> a technology.

But it does epitomize PHP's overall paradigm of "you want to add
funtionality for XYZ? ok lets drunkenly add support for it without
tryign to be consistent or plan for anything in the future.

>>> of life with all tools, deal with it. And last but not least, you do not
>>
>> And PHP tends to have a greater majority of them, have you ever
>> managed PHP on multiple servers? If you have you kwo exactly what I'm
>> referring to.
>
> I maintain 13 servers in total, each of them have PHP installed, and

try 13000 :) 13 is child's play and can be easily managed.

>>> have to be root to do anything with PHP, or indeed Apache except to
>>
>>
>> I was referring to building PHP/Apache in general *
>
>
> You do not need to be root to build PHP or Apache, or in fact anything
> else, so I'm not sure where you're getting that requirement from.

So any user on your systems can recompile apache or PHP at will?

>>> listen on a port lower than 1024, which is true for all tools since
>>> it's a platform limitation.
>>
>>
>> * I'm speaking in generalitites of working with PHP not specifics
>> components of the technology.
>
> In that case I would point out that your personal experiences with PHP
> are not necessarily a reflection on PHP. I hope you don't take offense

My personal experiences with PHP and many other internet technologies is
quite extensive.

> Quoting your original post... "it uses perl's MIME tools and SMTP
> tools". How is that not saying "PEAR or any specific package used Perl"?

Because I was refering to the URL I'd sent to Perl's Mail::Sender::Easy
module.

> Your solution was not "better" given the context of the question.
> Specifically that the question was asking about doing something in PHP
> and was asked on the PHP list meaning it's not a great leap to assume
> the guy need a solution in PHP.

A solution is a solution, PHP is just one tiny option, I was offering an
easier to work with alternative.

> Feel free to ignore the rest of this post, which I hope you'll take in
> the spirit it is meant, but please answer me this. What has PHP done to
> you? Why are you so anti-PHP? And specifically why are you on a PHP list
> suggesting people use a different technology?

PHP has all the problems I've been specifying, that costs time and
money, and I'm sick of it :)

I'm on this list because I am a developer for a company that makes an
apache install system and I needed to find out some info on the specific
oddness of PHP4 and PHP5's --with-mysql and --with-mysqli options so
that its would work properly.

Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what makes
PHP the last choice for any project.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Bastien Koert wrote:

> Then Please, stop posting here...it just is not constructive...

I will, but I think it is

> If you have these issues that need addressing to make it a better
> langauge, then talk to the nice people at Zend and get invovled in
> making things better.

No thanks, trying to get out of that pit of despair. I am however trying
to help make things better by doing non-PHP stuff.

> All the rest if useless diatribe.

Its not useless if one person benefits from it and at least considers
that an alternative to PHP may be a better choice and that PHP is not
gods gift to nerds but rather Satan's snare of the nerds :)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

------=_Part_32046_22395846.1147469067457
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

2006/5/12, JupiterHost.Net :
>
>
> > It's a fact that I can't deny any of the bad points you have exposed
> about
> > PHP. I even agree with you that most of this problems are really awful
> and
> > it's pointless to hide them. But the fact that PHP is by preference the
> > language for developing small and middle web solutions aimed to be
> economic
> > and rapidly developed is also undeniable. All languages have their pros
> and
> > cons, and trying to compare them outside of the context of the target
> > market
> > is pointless. It just happens that PHP pros fit better the desires of
> the
> > web solutions market, and they also don't care much about current PHP
> cons.
>
> Most people aren't aware of the cons, thats my point :)


Developers are aware (well most of them). Designers are not, project leader=
s
are not (with the exception of a few), marketing people are not, and all th=
e
people higher up in the administration are not. This is mostly our fault,
there really aren't enough effort applied to educate those outside the IT
world.

For example:
> If Mr. big wig was aware that phpBB has a history if being uber
> hackable and even being used in a rootkit scheme a time or two he'd not
> choose PHP. But its shiny so he says "go with that it looks nice".
>
> That is how its popularity has grown, ignorance of the facts.
>
> > Anyway, this market is evolving and its needs are changing, so it's
> normal
> > for developers to try and anticipate future development needs and try t=
o
> > make PHP fit into other philosophies, methodologies or technologies it
> was
> > not designed to work with, and everyone who has tried this (including
> me)
> > have started to hate PHP in a certain way. But that's all there is to
> it, I
> > hate not having a proper application framework, I hate not having
> > namespaces, I hate the overhead of working with OOP, I hate magic
> quotes,
> > but I still use PHP because it is still the most appropiate development
> > enviroment for a small or middle sized web solution.
>
> Why not use Perl, it has all the "pros" but does not have the cons :)


Because it has cons, and lots of them. It's not a language who was designed
for web development and this becomes a hassle. Its language constructions
are not as intuitive as other languages, there are too many ways of doing
the same thing, and too many different "code conventions" (if they can be
called as such). So it really becomes complicate to make one perl developer
work with another perl developer. There are too many basic data structures
for a scripting language, PHP arrays work better in almost any situation,
are easier to understand and use. Debugging a perl application requires a
higher level of programming skills.

In fact, I use it for several high volumn websites:
> - with persistent database connections and persistently running
> instances of the script
> (which is the *only* positive PHP has, except it means running PHP
> as "nobody" and with really really bad permissions)
> - without doing *anything* with apache
> - works with SuExec so it runs as the user so the permissions can be
> 700 and config files 600 - try that with PHP without days of fiddling
> and breaking stuff and finally giving up ;)
>
> Now you have the only "benefit" of PHP (but better) without *any* of its
> downside.
>
> > I'm guessing this part, but I think you think alike and that's the
> reason
> > you're still on this list and trying to make a point out of your bad
> > experiences with PHP. We can still hope that this problems will be
> solved
>
> It won't, for "backwards compatibility" they'll have to keep the cobbled
> up mess. Or else make it new from scratch and remove the crap, but in
> that case itd be a brand new langauge and would have all the problems
> inherent with that :)


I think they have proved they don't care too much about backward
compatibility. You have just to see what happened to the [] and {} string
operator: deprecated, undeprecated and so on. They only care about keeping
the core features of PHP (those that really made the language stand where i=
t
is).

> Thanks for sharing your opinion and concerns, I really appreciate them.
>
> My pleasure, I've been managing hundreds of servers for nearly a decade
> and PHP has always had seriouse drawbacks. I've really honestly tried to
> make a go of it but its just to much overhead to be worth it, IMHO :)


PHP doesn't have too much overhead when it's used in its most primitive way=
..
Everything procedural, everything on arrays and only load what you need.
This way it can run as fast as anyone. But this can only be used for small
solutions and some medium web solutions, it isn't applyable to every need.

--
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

------=_Part_32046_22395846.1147469067457--

Re: Re: Sending filing attachments using PHP

JupiterHost.Net wrote:
> Stut wrote:
>
>>>> What planet are you on? Seriously? Because PEAR does not need to be
>>>> compiled into PHP. Zend Optimizer is no different to the optimizers
>>>
>>>
>>> I was referring to --with-pear, sorry "compiled" was not the right
>>> word *
>>
>> I'm not familiar with the switch you are referring to. If you look into
>
> in PHP source:
> ./configure --help

I've had a look and it would appear that all that switch does is install
PEAR for you during the build process. That doesn't change the fact that
it's still just a collection of PHP classes and does not require
rebuilding of PHP to benefit from it.

>> PEAR a bit closer you will find that it is simply a package of
>> classes. It does not need any changes to your PHP binary for it to
>> work correctly.
>>
>>>> available for other scripting languages. Version mismatches are a fact
>>>
>>>
>>> I was referring to how Zend Opt is "required" for some stuff mainly
>>> because its necessary to offset the bloat. *
>>
>>
>> I'm not sure what gives you the impression that Zend Optimizer is
>> "required" for anything. ZO is a system for pre-compiling PHP code to
>
> If a PHP system has been "Optimized" then it requires ZO. Most admins
> need to have ZO since at least one of theri users will want to use sucha
> PHP system.

I think you're grossly over-estimating the number of PHP systems that
use Zend Optimizer, not so much as an actual number but more as a
percentage of all software written in PHP.

You're also making it sound like adding ZO to a PHP installation is a
mammoth task... it's not. It's just as simple as building PHP itself.

>> bytecodes such that the PHP source files do not need to be interpreted
>> each time they are run. While it is true that some commercial software
>> written in PHP is encoded and requires ZO, but this is a choice of
>> that particular developer and is not attributable to PHP as a language
>> or as a technology.
>
> But it does epitomize PHP's overall paradigm of "you want to add
> funtionality for XYZ? ok lets drunkenly add support for it without
> tryign to be consistent or plan for anything in the future.

How so? Take any other interpreted language, and you don't usually get
pre-compilation for free. Correct me if I'm wrong but this goes for Perl
as much as it does for PHP. You have to 'jump through hoops' to get it.

I'll freely agree that there are a number of things that exist in PHP
that are not ideal, and could appear to have been implemented by a
drunken developer trying to meet a deadline. However, having been a
lurker on the PHP-Dev list for a long time now I can say with absolute
confidence that most of the decisions made regarding what gets into PHP
and what doesn't are well-justified.

PHP is not a small system, and it takes a huge effort to manage the
ongoing development. Mistakes have been made and undoubtedly will
continue to be made, but I'm sure the same can be said for any
similarly-sized open-source project.

>>>> of life with all tools, deal with it. And last but not least, you do
>>>> not
>>>
>>> And PHP tends to have a greater majority of them, have you ever
>>> managed PHP on multiple servers? If you have you kwo exactly what I'm
>>> referring to.
>>
>> I maintain 13 servers in total, each of them have PHP installed, and
>
> try 13000 :) 13 is child's play and can be easily managed.

IMHO, 13,000 servers should be just as easy to manage as 13 - it all
depends on the infrastructure (in terms of tools) you have in place to
assist you in the task.

Out of curiosity, why do you find it easier to manage Perl on 13,000
servers? What specific advantages does it have over PHP when it comes to
this?

>>>> have to be root to do anything with PHP, or indeed Apache except to
>>>
>>>
>>> I was referring to building PHP/Apache in general *
>>
>>
>> You do not need to be root to build PHP or Apache, or in fact anything
>> else, so I'm not sure where you're getting that requirement from.
>
> So any user on your systems can recompile apache or PHP at will?

Yeah, I don't stop them - more hassle than it's worth. But they'll be
compiling it in their own directories, they'll be running their own
copies. They can't interfere with the systems installation of either
because file permissions don't let them, but that doesn't stop them
working on their own copies of it.

Any user with shell access with the required build tools available to
them will be able to do the same. If you think otherwise I encourage you
to try it.

>>>> listen on a port lower than 1024, which is true for all tools since
>>>> it's a platform limitation.
>>>
>>> * I'm speaking in generalitites of working with PHP not specifics
>>> components of the technology.
>>
>> In that case I would point out that your personal experiences with PHP
>> are not necessarily a reflection on PHP. I hope you don't take offense
>
> My personal experiences with PHP and many other internet technologies is
> quite extensive.

I don't doubt that, but I'm not understanding what Perl gives you that
makes it easier to manage than PHP. Please explain it to me so I can
learn something from this exchange. You clearly feel quite passionate
about it, so please share.

>> Quoting your original post... "it uses perl's MIME tools and SMTP
>> tools". How is that not saying "PEAR or any specific package used Perl"?
>
> Because I was refering to the URL I'd sent to Perl's Mail::Sender::Easy
> module.

Reading back I see that now, but it was a bit ambiguous. My apologies.

>> Your solution was not "better" given the context of the question.
>> Specifically that the question was asking about doing something in PHP
>> and was asked on the PHP list meaning it's not a great leap to assume
>> the guy need a solution in PHP.
>
> A solution is a solution, PHP is just one tiny option, I was offering an
> easier to work with alternative.

Without adequately explaining why it's easier. And more to the point you
are still on a PHP list, and as I've stated before, the question was
clearly asking for a PHP solution.

>> Feel free to ignore the rest of this post, which I hope you'll take in
>> the spirit it is meant, but please answer me this. What has PHP done
>> to you? Why are you so anti-PHP? And specifically why are you on a PHP
>> list suggesting people use a different technology?
>
> PHP has all the problems I've been specifying, that costs time and
> money, and I'm sick of it :)

Yeah, I got that already :). What I haven't grok'd is what specifically
makes Perl easier and therefore cheaper to manage.

> I'm on this list because I am a developer for a company that makes an
> apache install system and I needed to find out some info on the specific
> oddness of PHP4 and PHP5's --with-mysql and --with-mysqli options so
> that its would work properly.
>
> Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what makes
> PHP the last choice for any project.

Again, this is a statement that makes no sense to me. You've made a
statement saying you hate something without explaining why. Do you see
why it's very hard to learn from you when you don't justify your hatred?
What's the problem with the MySQL modules available for PHP? I
personally have never had a problem with them, but if there is a better
way I'm all ears.

-Stut

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

>> in PHP source:
>> ./configure --help
>
> I've had a look and it would appear that all that switch does is install
> PEAR for you during the build process. That doesn't change the fact that
> it's still just a collection of PHP classes and does not require
> rebuilding of PHP to benefit from it.

sure no problem, again mostly I was speaking in gernalities about how
its works and referencing the switch since you'd never heard of ti.

> You're also making it sound like adding ZO to a PHP installation is a
> mammoth task... it's not. It's just as simple as building PHP itself.

Which is a mammoth task ;)

> How so? Take any other interpreted language, and you don't usually get

Even though PECL and PEAR alleviate some of the headache by trying to be
CPAN, much funtionality is based on build options (mysql, curl, etc)

So if I find that my server does not have, say, mysql support built in
or I need a special kind (see ./configure --help for a list) then PHP
will most likely need recompiled.

If it breaks, you may break PHP for everyone, it may even take down
apache if the .so got goofy.

With Perl
perl -MCPAN -e 'install DBD::mysql;'

if it breaks then
- all scripts still work
- apache still works

> pre-compilation for free. Correct me if I'm wrong but this goes for Perl
> as much as it does for PHP. You have to 'jump through hoops' to get it.

one command, no possiblity of breaking anything, one hoop, very low to
the ground and about ten feet tall :)

> Out of curiosity, why do you find it easier to manage Perl on 13,000
> servers? What specific advantages does it have over PHP when it comes to
> this?

Perl just works and make sense so its easier to code with. Any issue
sthat do come up now and then are usually resolved by a moduel upgrade,
one CPAN cpmmand :)

>> So any user on your systems can recompile apache or PHP at will?
>
> Yeah, I don't stop them - more hassle than it's worth. But they'll be

Ok, i guess I'm refering to running a webserver that all the user's
share. If "bob" needs --with-curl then PHP needs to be recompiled. in
practice most hosting customers are hosting customers because they
woudln't knwo anythgin about compiling their own anything.

Its all really besides the point though, perhaps I shoudl have just
phrased it "you have to recompile some major stuff just to add minor
functionality"

>> My personal experiences with PHP and many other internet technologies
>> is quite extensive.
>
> I don't doubt that, but I'm not understanding what Perl gives you that
> makes it easier to manage than PHP. Please explain it to me so I can

As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
PHP" rant :)

> learn something from this exchange. You clearly feel quite passionate
> about it, so please share.

Actually since most everyone has expressed an interest in stopping this
thread, I think I will. Teh facts are there do as you wish :)

>> A solution is a solution, PHP is just one tiny option, I was offering
>> an easier to work with alternative.
>
>
> Without adequately explaining why it's easier. And more to the point you

Sure I did, no one wants to hear it though :)

> are still on a PHP list, and as I've stated before, the question was
> clearly asking for a PHP solution.

True enough, but if you want to be strict then why not send them to a
none DB list?

>>> Feel free to ignore the rest of this post, which I hope you'll take
>>> in the spirit it is meant, but please answer me this. What has PHP
>>> done to you? Why are you so anti-PHP? And specifically why are you on
>>> a PHP list suggesting people use a different technology?
>>
>> PHP has all the problems I've been specifying, that costs time and
>> money, and I'm sick of it :)
>
> Yeah, I got that already :). What I haven't grok'd is what specifically
> makes Perl easier and therefore cheaper to manage.

As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
PHP" rant :)

>> Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what
>> makes PHP the last choice for any project.
>
> Again, this is a statement that makes no sense to me. You've made a
> statement saying you hate something without explaining why. Do you see

Because its got *soooo* many problems, security, development, admin wise
- details throughout this thread :)

> why it's very hard to learn from you when you don't justify your hatred?
> What's the problem with the MySQL modules available for PHP? I

Those configure flags have so many combinations to get unpredicatabel
behavior this is the pseudo thought process while doing it:

--with-mysql (make sense so far)

but lest add the super duper mysqli stuff:

Oi crap what arg do you give it depending on what --with-mysql 's value is?
--with-mysql=/usr --with-mysqli=path_to_mysql_config
--with-mysql --with-mysqli=/usr

Is all of that mess the same on PHP 4 and 5 ?

What if you have mysql 4.0, 4.1, or 5 ?

and once you get your head wrapped around it are all the badly named
funitons gogin to behave the same?

> personally have never had a problem with them, but if there is a better
> way I'm all ears.

yep, use Perl's DBI modules or some other API (C, Python, Ruby,
*anything*) to MySQL that is consistently easier to setup and use

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

> there really aren't enough effort applied to educate those outside the IT
> world.

Working on it :)

>> > but I still use PHP because it is still the most appropiate development
>> > enviroment for a small or middle sized web solution.
>>
>> Why not use Perl, it has all the "pros" but does not have the cons :)
>
> Because it has cons, and lots of them. It's not a language who was designed

"it is still the most appropriate development environment.."As I
stated previously, I'm not trying to do a Perl vs PHP debate but rather
"use anything but PHP" the "why not use Perl" was directed at the
statement.

In other words "Why is the most appropriate" when its a security problem
and a hassle, and zillions of other technologies do the same stuff, and
more, and much much better.

> for web development and this becomes a hassle. Its language constructions

Why/ just output headers and HTML and you're done. Separate logic and
presentation.

> are not as intuitive as other languages, there are too many ways of doing
> the same thing, and too many different "code conventions" (if they can be

Oi, did you even look at the url I sent? all the randomly named
functions that do the same thing?

> called as such). So it really becomes complicate to make one perl developer
> work with another perl developer. There are too many basic data structures
> for a scripting language, PHP arrays work better in almost any situation,
> are easier to understand and use. Debugging a perl application requires a
> higher level of programming skills.

Not really. You're just used to PHP data structures, thats all.

> PHP doesn't have too much overhead when it's used in its most primitive
> way.

But when is it? Mostly never, people always need this or that option
compiled in and pretty soon: a 20 Meg binary and lots of headache :)

> Everything procedural, everything on arrays and only load what you need.
> This way it can run as fast as anyone. But this can only be used for small
> solutions and some medium web solutions, it isn't applyable to every need.

Thats a programmer doing a good job, and that can be done in any
language. Its no positive feature of PHP.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

I think we may have to agree to disagree. I love PHP. I've never had a
problem with it that couldn't be solved that's made me want to switch.

Just to make it clear I do try the so-called "up-and-coming" development
trends, and over the years have tried most of the existing systems. I
recently started using Rails, which has some very nice features but I
find it far too restrictive for development of anything more than 'toy'
apps. Just wanted to make the point that I'm not pro-PHP for no reason.
I've tried the rest, I've settled on what I believe to be the best.

JupiterHost.Net wrote:
>>> in PHP source:
>>> ./configure --help
>>
>> I've had a look and it would appear that all that switch does is
>> install PEAR for you during the build process. That doesn't change the
>> fact that it's still just a collection of PHP classes and does not
>> require rebuilding of PHP to benefit from it.
>
> sure no problem, again mostly I was speaking in gernalities about how
> its works and referencing the switch since you'd never heard of ti.
>
>> You're also making it sound like adding ZO to a PHP installation is a
>> mammoth task... it's not. It's just as simple as building PHP itself.
>
> Which is a mammoth task ;)

No more so than building Perl or Python or Ruby IMHO.

>> How so? Take any other interpreted language, and you don't usually get
>
> Even though PECL and PEAR alleviate some of the headache by trying to be
> CPAN, much funtionality is based on build options (mysql, curl, etc)

Again, this is not true. As far as I know, PHP is architected as a core
engine with modules for all userland functions, including what could be
considered basic features such as array operations. What this means is
that each module that provides additional functionality can be built as
a dynamically loaded object. That is to say separate from any other
functionality.

> So if I find that my server does not have, say, mysql support built in
> or I need a special kind (see ./configure --help for a list) then PHP
> will most likely need recompiled.

Not so. Or rather, I should say, build the .so.

> If it breaks, you may break PHP for everyone, it may even take down
> apache if the .so got goofy.
>
> With Perl
> perl -MCPAN -e 'install DBD::mysql;'
>
> if it breaks then
> - all scripts still work
> - apache still works

Build the .so. Run php on the command line with a script that uses the
dl function to dynamically load the new module. If it doesn't work it
hasn't broken anything since it's dynamically loaded. If it does work
then you update the configuration file that lists the extensions to be
loaded at startup and restart Apache.

>> pre-compilation for free. Correct me if I'm wrong but this goes for
>> Perl as much as it does for PHP. You have to 'jump through hoops' to
>> get it.
>
> one command, no possiblity of breaking anything, one hoop, very low to
> the ground and about ten feet tall :)

Likewise with adding MySQL to PHP, as long as you do it right. Do it the
lazy way (which is just to recompile) and you could encounter problems.

>> Out of curiosity, why do you find it easier to manage Perl on 13,000
>> servers? What specific advantages does it have over PHP when it comes
>> to this?
>
> Perl just works and make sense so its easier to code with. Any issue
> sthat do come up now and then are usually resolved by a moduel upgrade,
> one CPAN cpmmand :)

Same with PHP.

>>> So any user on your systems can recompile apache or PHP at will?
>>
>> Yeah, I don't stop them - more hassle than it's worth. But they'll be
>
> Ok, i guess I'm refering to running a webserver that all the user's
> share. If "bob" needs --with-curl then PHP needs to be recompiled. in
> practice most hosting customers are hosting customers because they
> woudln't knwo anythgin about compiling their own anything.
>
> Its all really besides the point though, perhaps I shoudl have just
> phrased it "you have to recompile some major stuff just to add minor
> functionality"

We're talking about different things. The only point I was making is
that building PHP and Apache do not *require* root. In fact only
installing it requires root. You certainly don't need root to run
either. You seem to be extending this to include whether users are
capable. That's irrelevant - they can if they want to, but in most cases
it's not worth their while.

In your example of "bob" and his CURL module, it's as simple as building
to .so (bob can do this if he's able), sticking it in the right
directory and running a test script (as I described above) to ensure it
doesn't break anything. No recompilation of PHP, or any other "major
stuff" needed, and nothing gets broken.

>>> My personal experiences with PHP and many other internet technologies
>>> is quite extensive.
>>
>> I don't doubt that, but I'm not understanding what Perl gives you that
>> makes it easier to manage than PHP. Please explain it to me so I can
>
> As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
> PHP" rant :)

And that justifies it how? All I'm getting is an "I hate PHP and nothing
you say will sway me from that opinion". Is that accurate? Because if it
is I have better things to do with my time.

>> learn something from this exchange. You clearly feel quite passionate
>> about it, so please share.
>
> Actually since most everyone has expressed an interest in stopping this
> thread, I think I will. Teh facts are there do as you wish :)

Agreed, we should probably both give up. The "facts" are still in
dispute, but each to his or her own.

>>> A solution is a solution, PHP is just one tiny option, I was offering
>>> an easier to work with alternative.
>>
>> Without adequately explaining why it's easier. And more to the point you
>
> Sure I did, no one wants to hear it though :)
>
>> are still on a PHP list, and as I've stated before, the question was
>> clearly asking for a PHP solution.
>
> True enough, but if you want to be strict then why not send them to a
> none DB list?

Fair point, but it was still a *PHP* list not a generic DB list.

>>>> Feel free to ignore the rest of this post, which I hope you'll take
>>>> in the spirit it is meant, but please answer me this. What has PHP
>>>> done to you? Why are you so anti-PHP? And specifically why are you
>>>> on a PHP list suggesting people use a different technology?
>>>
>>> PHP has all the problems I've been specifying, that costs time and
>>> money, and I'm sick of it :)
>>
>> Yeah, I got that already :). What I haven't grok'd is what
>> specifically makes Perl easier and therefore cheaper to manage.
>
> As I stated I'm not doing a Perl vs PHP rant I'm doing an "anything but
> PHP" rant :)
>
>>> Which in fact PHP4/5 + --with-mysql[i] *is* a huge example of what
>>> makes PHP the last choice for any project.
>>
>> Again, this is a statement that makes no sense to me. You've made a
>> statement saying you hate something without explaining why. Do you see
>
> Because its got *soooo* many problems, security, development, admin wise
> - details throughout this thread :)

Yeah, about those security problems. You mentioned phpBB as an example.
You must be aware that nearly every problem related to security that has
ever been found in relation to PHP has been down to poor implementation
on the part of the script developer and not PHP itself. All other
languages and tools are open to the same type of problems, but
popularity and user-base of PHP cause bad press.

>> why it's very hard to learn from you when you don't justify your
>> hatred? What's the problem with the MySQL modules available for PHP? I
>
> Those configure flags have so many combinations to get unpredicatabel
> behavior this is the pseudo thought process while doing it:
>
> --with-mysql (make sense so far)
>
> but lest add the super duper mysqli stuff:
>
> Oi crap what arg do you give it depending on what --with-mysql 's value
> is?
> --with-mysql=/usr --with-mysqli=path_to_mysql_config
> --with-mysql --with-mysqli=/usr

Please enlighten me as to how other tools find the MySQL libs. As far as
I'm aware they do it in exactly the same way, namely an automatic search
which will occasionally fail which requires the ability to specify it in
the configure command.

> Is all of that mess the same on PHP 4 and 5 ?

Pretty much.

> What if you have mysql 4.0, 4.1, or 5 ?

Doesn't matter.

> and once you get your head wrapped around it are all the badly named
> funitons gogin to behave the same?

Badly named functions? There are some dodgy ones still in there for BC
reasons, but this has improved a lot since PHP 4 & 5 arrived.

>> personally have never had a problem with them, but if there is a better
>> way I'm all ears.
>
> yep, use Perl's DBI modules or some other API (C, Python, Ruby,
> *anything*) to MySQL that is consistently easier to setup and use

Again, we'll have to agree to disagree. For me PHP makes setting up and
using MySQL a breeze.

Anyway, I think we should end this here since we're clearly not making a
dent in each others opinion of PHP. Feel free to reply to me offlist if
you really want to continue, but I don't think there would be much point.

-Stut

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

Stut wrote:
> I think we may have to agree to disagree. I love PHP. I've never had a

Ah I completely forgot about this sort of fun thing that I find in my
email almost once a week, just got this one:

http://forums.gentoo.org/viewtopic-t-460727.html

now how many phpinfo() pages do you think there are and how many are
vulnerable to the cross-site scripting attack.

So this report means you have to upgrade your binary and it addresses:
- system level problems (buffer overflow, memory leak, potential crash)
- web based secuity attacks (corss-site scripting)
- code based security attacks (restriction bybasses)

*exactly* the sort of stuff thats jaded me :)

Time to upgrade each install of PHP on all 13 server's :)

The phpingo(0 reminds me of the one they had where a php file with only
this line:



would allow an attacker to upload a rootkit and damage the system,
saaaweeet ;p

or a cross site scripting/SQL injection thing that'd allow people to
post HTML to your site and make it show whatever they wanted...

good times, good times

Peace everyone, its been really fun :)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

php is not the only language susceptible to x-browser attacks... seems
unfair to single it out.

And as previously pointed out, many times it the developer's fault for
writing that insecure code

Bastien


>From: "JupiterHost.Net"
>To: php-db@lists.php.net
>Subject: Re: [PHP-DB] Re: Sending filing attachments using PHP
>Date: Fri, 12 May 2006 18:53:13 -0500
>
>
>
>Stut wrote:
>>I think we may have to agree to disagree. I love PHP. I've never had a
>
>Ah I completely forgot about this sort of fun thing that I find in my email
>almost once a week, just got this one:
>
>http://forums.gentoo.org/viewtopic-t-460727.html
>
>now how many phpinfo() pages do you think there are and how many are
>vulnerable to the cross-site scripting attack.
>
>So this report means you have to upgrade your binary and it addresses:
> - system level problems (buffer overflow, memory leak, potential crash)
> - web based secuity attacks (corss-site scripting)
> - code based security attacks (restriction bybasses)
>
>*exactly* the sort of stuff thats jaded me :)
>
>Time to upgrade each install of PHP on all 13 server's :)
>
>The phpingo(0 reminds me of the one they had where a php file with only
>this line:
>
>
>
>would allow an attacker to upload a rootkit and damage the system,
>saaaweeet ;p
>
>or a cross site scripting/SQL injection thing that'd allow people to post
>HTML to your site and make it show whatever they wanted...
>
>good times, good times
>
>Peace everyone, its been really fun :)
>
>--
>PHP Database Mailing List (http://www.php.net/)
>To unsubscribe, visit: http://www.php.net/unsub.php
>

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

Bastien Koert wrote:
> php is not the only language susceptible to x-browser attacks... seems
> unfair to single it out.

Why not? Its the only I've seen that actually has hackability built in!
(see below) So it singles itself out, thats the whole point :)

> And as previously pointed out, many times it the developer's fault for
> writing that insecure code

Yes developer does cross-site scripting suseptable code = developer's fault

* but if a script has *only* this as its content:



And *that* script has cross-site vulnerabilities is the programmer at
fault for writing bad code?

No, he's at fault for using PHP

I rest my case ;)

The only solution is to upgrade the binary.

That SUCKS big time!

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Am 2006-05-12 10:09:46, schrieb JupiterHost.Net:

> Right after rebuilding php and apache and breaking PHP funtionality for
> everyone, just so you can send a semi complex MIME message? That is the
> epitome of PHP's lameness and why I can't sit quietly by and not
> recommend an easy to install and use and maintain solution.

Hmmm, I send per day around 80.000 different E-Mails created
with php5 most of them are mime-encoded and multipart...

I do not know, which problems you have, but it works perfectly

Even complex multiparts with message/rfc822 and binaries inside.

OK, the message should not be bigger then 20 MByte except you
have a machine like mine... 32 CPU's and 64 GByte of memory.

> - no fiddling with apache

No problem for apache 1.3 with php5

> - no fiddling with the interpretet binary

apt-get install ...

> - no possibility of breaking anyone's scripts

It just works...

So why bother wit a language no ene knows how this crappy syntax works?

;-)

Greetings
Michelle Konzack


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Am 2006-05-12 15:39:44, schrieb JupiterHost.Net:

> Why not use Perl, it has all the "pros" but does not have the cons :)

Oh yes it has... Perl is a memory monster...

I have no problems to soupport over 17.000 Users on 32 CPU
machine with 64 GByte of memory using apache 1.3 and php5.

Perl would just kill the machine...

> In fact, I use it for several high volumn websites:
> - with persistent database connections and persistently running
> instances of the script
> (which is the *only* positive PHP has, except it means running PHP
> as "nobody" and with really really bad permissions)

Why this?

> - without doing *anything* with apache

apache servs only websites and the output of the php...


> - works with SuExec so it runs as the user so the permissions can be
> 700 and config files 600 - try that with PHP without days of fiddling
> and breaking stuff and finally giving up ;)

Sorry? - I do exactly the same with my 17.000 users using suphp.

Greetings
Michelle Konzack
Systemadministrator
Tamay Dogan Network
Debian GNU/Linux Consultant


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)


--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

Am 2006-05-12 11:58:37, schrieb JupiterHost.Net:

> I was referring to building PHP/Apache in general *

What do you talking about? -- I have compiled Apache and
php5 the standard way and ABSOLUTLY NOTHING was missing.

> >listen on a port lower than 1024, which is true for all tools since it's
> >a platform limitation.
>
> * I'm speaking in generalitites of working with PHP not specifics
> components of the technology.

???

> >Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is
> >another example of a pure-php class. It certainly does not use anything
> >perl related at all. I'd really like to know what makes you think it does.
>
> I never said PEAR or any specific package used Perl, I'd simply offered
> a better solution that happend to be done in Perl.

No, it is NOT a better solution, because if I use perl I
have to maintain TWO scripting languages and install I do
not know how many modules from CPAN... maybe 100-200?

> Good day to all, sorry if I was to ambiguouse or I've offended.

Good by!



--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Sending filing attachments using PHP

Am Freitag, 12. Mai 2006 00:33 schrieb Ron Piggott (PHP):
> Does any one know how to send a file attachment using PHP?

You need to reformulate the problem. Does any one know how to create a
mime/mulipart message with php?



Best Regards,

Oliver

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

> So why bother wit a language no ene knows how this crappy syntax works?

Because you are mistaken based on your preference and experience and
calling it "crappy" is not a very professional way to make your argument.

Again I was simply pointing out some *major* drawbacks of PHP, not doing
a one lang vs another comparison.

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Sending filing attachments using PHP

Michelle Konzack wrote:

> Am 2006-05-12 15:39:44, schrieb JupiterHost.Net:
>
>
>>Why not use Perl, it has all the "pros" but does not have the cons :)
>
>
> Oh yes it has... Perl is a memory monster...

Anything is a memory monster if the task is memory intensive.

many benchmarks of multi languages (not just Perl/PHP) doing similar
task show PHP as one of the highest actually.

> I have no problems to soupport over 17.000 Users on 32 CPU
> machine with 64 GByte of memory using apache 1.3 and php5.
>
> Perl would just kill the machine...

Thats good that you have had good experince on one machine or cluster.

Have you tried 17000 servers yet?

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Re: Sending filing attachments using PHP

Michelle Konzack wrote:

> Am 2006-05-12 11:58:37, schrieb JupiterHost.Net:
>
>
>>I was referring to building PHP/Apache in general *
>
>
> What do you talking about? -- I have compiled Apache and
> php5 the standard way and ABSOLUTLY NOTHING was missing.

Great, I'm talking about managing multiple servers with multi needs.
Generally its a cludge. If you have to build it only one a hadnfull of
servers only when updates come upt, super.
>
>>>listen on a port lower than 1024, which is true for all tools since it's
>>>a platform limitation.
>>
>>* I'm speaking in generalitites of working with PHP not specifics
>>components of the technology.
>
>
> ???

Generally: PHP is more prone to have the "true for all tools" probelms.

>>>Yeah, you're definitely smoking somethin'. The PEAR package Mail_Mime is
>>>another example of a pure-php class. It certainly does not use anything
>>>perl related at all. I'd really like to know what makes you think it does.
>>
>>I never said PEAR or any specific package used Perl, I'd simply offered
>>a better solution that happend to be done in Perl.
>
>
> No, it is NOT a better solution, because if I use perl I
> have to maintain TWO scripting languages and install I do
> not know how many modules from CPAN... maybe 100-200?

I install about 10 generally. I think you're starting to get into a "my
dad can beat up your dad" thing which is pointless.

>>Good day to all, sorry if I was to ambiguouse or I've offended.
>
>
> Good by!

Seriously, chill, I wasn't getting personal. Reckon I touched a nerve.

Its too bad if you don't want to consider another idea. your loss not
mine :)

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Re: Re: Re: Sending filing attachments using PHP

Just wanted to ^bump^ this ridiculously prolonged flame-like thread
which will surely be annulled in the chronicles of PHP history



;-)

>
>
> Michelle Konzack wrote:
>
>> Am 2006-05-12 11:58:37, schrieb JupiterHost.Net:
>>
>>
>>>I was referring to building PHP/Apache in general *
>>
>>
>> What do you talking about? -- I have compiled Apache and
>> php5 the standard way and ABSOLUTLY NOTHING was missing.
>
> Great, I'm talking about managing multiple servers with multi needs.
> Generally its a cludge. If you have to build it only one a hadnfull of
> servers only when updates come upt, super.
>>
>>>>listen on a port lower than 1024, which is true for all tools since
>>>>it's a platform limitation.
>>>
>>>* I'm speaking in generalitites of working with PHP not specifics
>>>components of the technology.
>>
>>
>> ???
>
> Generally: PHP is more prone to have the "true for all tools"
> probelms.
>
>>>>Yeah, you're definitely smoking somethin'. The PEAR package
>>>>Mail_Mime is another example of a pure-php class. It certainly does
>>>>not use anything perl related at all. I'd really like to know what
>>>>makes you think it does.
>>>
>>>I never said PEAR or any specific package used Perl, I'd simply
>>>offered a better solution that happend to be done in Perl.
>>
>>
>> No, it is NOT a better solution, because if I use perl I
>> have to maintain TWO scripting languages and install I do
>> not know how many modules from CPAN... maybe 100-200?
>
> I install about 10 generally. I think you're starting to get into a
> "my dad can beat up your dad" thing which is pointless.
>
>>>Good day to all, sorry if I was to ambiguouse or I've offended.
>>
>>
>> Good by!
>
> Seriously, chill, I wasn't getting personal. Reckon I touched a nerve.
>
> Its too bad if you don't want to consider another idea. your loss not
> mine :)
>
> --
> PHP Database Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.1.392 / Virus Database: 268.5.6/340 - Release Date:
> 15/05/2006
>



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.392 / Virus Database: 268.5.6/340 - Release Date: 15/05/2006

--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php