Re: [PHP] Include an encoder into PHP distribution?

From: Manuel Lemos (mlemos_at_acm.org)
Date: 11/17/03


To: php-general@lists.php.net
Date: Sun, 16 Nov 2003 23:29:17 -0200

Hello,

On 11/16/2003 08:44 PM, Burhan Khalid wrote:
>>> IMHO, if you really want to start some political debate or push your
>>> warped ideas on everyone, you can do it on another list.
>>
>>
>>
>> I am not pushing anything. I am just explaining why GPL extensions and
>> libraries will not be accepted by the PHP group.
>>
>> I don't see the point in your hostility trying to act as censorship.
>> You are not adding anything to the thread.
>
>
> I agree with you here Manuel. Thanks for the explanation about GPL and
> BSD, and it was a good point to add. However, I think that an encoder
> should not be part of the default php distribution, because it would
> *force* people to use the encoder supplied (I'm sure there would be
> means to use another encoder).

Not at all. An encoder/loader is just an extension can be enabled or
disabled anytime. PHP already comes with extensions for the same
purposes. Leaving it to choice of the user would make it more democratic.

OTOH, it would provide further encouragement for commercial extension
developers to do better than they do today. According to the Turck
benchmarks Turck does better than all commercial extensions in script
caching, including Zend and Ioncube's. Certainly part of this is due to
the fact that Turck can optimize compiled PHP code better.

So, the users may ask, why pay for commercial extensions if there is a
better free extension? Just because commercial extension companies
invested more in advertising to get more visibility and apparent
credibility? I don't think so.

> Also, it would seem that PHP was endorsing one product over another, and
> such things are never good. As far as Zend goes, I don't think that
> they control anything...if anything, they have probably increased the
> visibility of php by essentially creating an entire company around it.
> Sure they contribute extensions to the php core, but anyone can do that
> -- the source is available for free.

That is a very naive view of the PHP status quo. Zend develops the core
engine that runs PHP. It is not a trivial task to do that. It is much
more trivial to develop the extensions for which they charge thousands
of dollars.

As for Zend not controlling anything, that is totally out of the
reality. Zend has been acting behind the scenes to keep away competing
extensions. Just as APC authors that were victim of of major boycotts
from Zend.

Furthermore, within the PHP group there is inconsistent treatment
regarding the use of name PHP for which the PHP Group does not even own
a trademark AFAIK.

For instance, there was a product named originally PHP encoder that the
PHP Group made the author rename it and now it is called PHTML encoder.

http://www.rssoftlab.com/phpenc.php

This would not be a problem if everybody was treated the same way.
However, Zend has in its pages a logo that says: Zend the PHP company.

http://www.zend.com/images/Zend_logo_small.gif

So, how come rssoftlab people may not call their product PHP encoder and
  Zend can call themselves the PHP company? It seems that everybody is
equal but some (Zend) are more equal than others.

For the matter, it is irrelevant for me if a rssoftlab uses PHP encoder
as their product name and Zend call themselves the PHP company. I would
not be surprised if this episode had the touch of Zend tentacles, but of
course that is just yet another episode that went behind the scenes so
we can only make suppositions!

> What I'm afriad is if things like "why don't we include x in the default
> php install" start, then soon we'll have "why don't we include y in the
> default php install", which would lead to unecessary bloat -- and I

Too late. PHP is already very bloated. That is why you can build many
extensions as shared libraries and enable them at run time.

> don't think anyone wants that. One thing I like about php is that it is
> trimmed down, and web specific -- so anyone can download other
> components an integrate them.

One thing is having plugable extensions that may not be loaded at the
same time. Another thing is having plugabble extensions that are shipped
with the main PHP distributions. The idea of John seems more like the
later and let people decide which extensions to use.

-- 
Regards,
Manuel Lemos
Free ready to use OOP components written in PHP
http://www.phpclasses.org/


Relevant Pages

  • RE: STG Security Advisory: [SSA-20041215-17] Vulnerability of uploading files with multiple exten
    ... "multiple extensions" behaviour in the past. ... There are a huge number of 3rd party PHP scripts out there ... upload a file without a registered MIME type are somewhat reduced. ... extensions behaviour for handlers as there seemed no legitimate ...
    (Bugtraq)
  • Re: [PHP] Include an encoder into PHP distribution?
    ... >>included in the core PHP distribution precisely because it compromises ... I was not saying or implying that Zend controls PHP alone. ... you don't know if Turck author wants to change its ... optimizer that is used by either the cache and the encoder, ...
    (php.general)
  • Loading DLLs from different path
    ... PHP is a popular server-side scripting language for web servers. ... It popularity is mainly due that it has many 3rd party extensions. ... The issue is that our DLL is dependent on RPC application server API DLLs in a different folder. ... The problem is that we never recommended putting dlls on the PATH nor do we recommend for our customers to have copies of DLLS over all the place. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Protecting PHP Code
    ... > I'd use Zend because it's closly tied with the PHP group. ... Just buy the encoder and forget the rest... ... of the project other than developing requirements then it is most likely ...
    (comp.lang.php)
  • Re: php?
    ... Also does this mean i can run php on the subsites while not affecting the ... When you use PHP with FrontPage 2003, you create the overall Web page design ... If you do not administer your own Web server, ... Disable features that require the FrontPage Server Extensions ...
    (microsoft.public.windows.server.sbs)