NEOHAPSIS - Peace of Mind Through Integrity and Insight

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com

Neohapsis > Archives > PHP Discussion Digest> 2008-02

php-general Digest 8 Feb 2008 07:56:22 -0000 Issue 5281

php-general-digest-helplists.php.net
Date: Fri Feb 08 2008 - 01:56:22 CST

Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

php-general Digest 8 Feb 2008 07:56:22 -0000 Issue 5281

Topics (messages 268899 through 268928):

Re: php file extension
        268899 by: MaryAnn Woodall
        268901 by: Shawn McKenzie
        268902 by: Andrew Ballard
        268903 by: Jason Pruim

Re: Profiling with register_tick_function / declare
        268900 by: McNaught, Scott
        268904 by: Shawn McKenzie
        268905 by: Shawn McKenzie
        268906 by: McNaught, Scott
        268920 by: Jochem Maas
        268922 by: Daniel Brown

Re: PHP Source code protection
        268907 by: Greg Donald
        268909 by: Daniel Brown
        268914 by: Greg Donald
        268919 by: Daniel Brown
        268923 by: Andrés Robinet

Re: PHP program to download sites
268908 by: Greg Donald

Re: Recommended ORM for PHP
268910 by: Manuel Lemos
268911 by: Greg Donald

Re: date() and wrong timezone (or time)
268912 by: Jochem Maas

How to parse this kind of XML
        268913 by: VamVan
        268915 by: Nathan Nobbe
        268916 by: VamVan
        268917 by: Daniel Brown
        268921 by: Nathan Nobbe

Re: urgently help required in integration of PHP and Geronimo
268918 by: Chris

killing a process through php webservice
        268924 by: Fahad javed
        268925 by: Paul Scott
        268926 by: Chris
        268927 by: Andrés Robinet
        268928 by: Per Jessen

Administrivia:

To subscribe to the digest, e-mail:
php-general-digest-subscribelists.php.net

To unsubscribe from the digest, e-mail:
php-general-digest-unsubscribelists.php.net

To post to the list, e-mail:
php-generallists.php.net

----------------------------------------------------------------------

attached mail follows:

Just starting to use php on my webpages. If I save a file as .php
or .php4 are they the same file. For example is index.php the same as
index.php4?

MaryAnn

attached mail follows:

MaryAnn Woodall wrote:
> Just starting to use php on my webpages. If I save a file as .php or
> .php4 are they the same file. For example is index.php the same as
> index.php4?
>
> MaryAnn

Depends upon what your server is set to parse as PHP. AFAIK, the only
portable extension would be .php.

-Shawn

attached mail follows:

On Feb 7, 2008 2:49 PM, MaryAnn Woodall <mawoodallearthlink.net> wrote:
> Just starting to use php on my webpages. If I save a file as .php
> or .php4 are they the same file. For example is index.php the same as
> index.php4?
>
> MaryAnn
>

No, they have different name and are different files. It would depend
on your system's configuration whether one would be the folder index
for the directory, and whether .php4 is even processed by PHP.

Andrew

attached mail follows:

Hi MaryAnn

I would recommend if you are going to be sending these files out to be
used on a server other then you own, such as a clients server, leave
the file as .php other wise the system admin for the client server
will have to reconfigure the server to also parse .php4 files.

But, if it's your server and you have full control over it there is no
reason you couldn't use .php4 or .aspSucks if you wanted to :)

Just don't expect other servers to pick them up :)

On Feb 7, 2008, at 2:49 PM, MaryAnn Woodall wrote:

> Just starting to use php on my webpages. If I save a file as .php
> or .php4 are they the same file. For example is index.php the same
> as index.php4?
>
> MaryAnn
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Jason Pruim
Raoset Inc.
Technology Manager
MQC Specialist
3251 132nd ave
Holland, MI, 49424
www.raoset.com
japruimraoset.com

attached mail follows:

Hi Shawn,

Thanks for the reply. I am using php5+ only, so I'm quite sure that passing
the object by reference like that is done automatically.

Aren't all objects are automatically passed by reference in php5, so
therefore & is deprecated? I tested your suggestion anyway, and it appeared
to make no difference.

The problem is to do with the scope that the "declare" directive affects.

Cheers anyway,

Scott

-----Original Message-----
From: Shawn McKenzie [mailto:nospammckenzies.net]
Sent: Friday, February 08, 2008 5:43 AM
To: php-generallists.php.net
Subject: [PHP] Re: Profiling with register_tick_function / declare

McNaught, Scott wrote:
> Hi there,
>
>
>
> Is it possible to make the declare(ticks=1) statement apply to *all*
> functions executed in a php script, regardless of scope?
>
>
>
> I wish to write a profiler script to basically dump all the function call
> times through the execution of a script. So far, I can only get it to
work
> for functions called via global scope.
>
>
>
> My code calls only one function from the global scope, and then a whole
lot
> of functions in classes are invoked. The tick function is only invoked
once
> from calling this one global function.
>
>
>
> Here is my code:
>
>
>
> <?php
>
> declare(ticks = 1);
>
>
>
> /**
>
> * Profiler
>
> *
>
> * version SVN: $Id$
>
> * author Scott McNaught
>
> */
>
> class Profiler
>
> {
>
> protected $m_arrProfileData = array();
>
> protected $m_strCurrentFunction = null;
>
> protected $m_iLastTime = null;
>
>
>
> /**
>
> * Begins profiling
>
> */
>
> public function start()
>
> {
>
> $this->m_iLastTime = time();
>
> }
>
>
>
> /**
>
> * Finishes profiling and dumps the results
>
> */
>
> public function end()
>
> {
>
> var_dump($this->m_arrProfileData);
>
> $this->m_arrProfileData = array();
>
> $this->m_strCurrentFunction = null;
>
> }
>
>
>
> public function tick()
>
> {
>
> $arrBacktrace = debug_backtrace();
>
>
>
> if (!isset($arrBacktrace[1]))
>
> {
>
> return;
>
> }
>
>
>
> $strFunction = $arrBacktrace[1]['function'];
>
>
>
> if (isset($arrBacktrace[1]['class']))
>
> {
>
> $strFunction = $arrBacktrace[1]['class'] . '::' .
> $strFunction;
>
> }
>
>
>
> $iTime = microtime(true);
>
>
>
> if (!isset($this->m_arrProfileData[$strFunction]))
>
> {
>
> $this->m_arrProfileData[$strFunction] = $iTime;
>
> }
>
>
>
> $this->m_arrProfileData[$strFunction] += $iTime -
> $this->m_iLastTime;
>
> $this->m_iLastTime = $iTime;
>
> $this->m_strCurrentFunction = $strFunction;
>
> }
>
> }
>
>
>
> $pProfiler = new Profiler();
>
> register_tick_function($pProfiler, 'tick'), true);
>
>
>
> ?>
>
>
>
>
>
> Then from index.php.
>
>
>
> <?php
>
>
>
> if(isset($_GET['profile']))
>
> {
>
> include('profiler.inc.php');
>
> }
>
>
>
> function execute()
>
> {
>
> $pClass = new SomeClass();
>
> $pClass->someFunction();
>
> }
>
>
>
> execute(); // TICK IS CALLED FROM EXECUTING THIS
>
>
>
> ?>
>
>
>
> So a tick is made from calling execute() from global scope, and that is
it.
> I want it to tick when someFunction() is called.
>
>
>
> I would really appreciate any help that anyone can give me with this as I
> have struggled with it for a while, and there is not much documentation
> about this anywhere.
>
> This could potentially benefit a lot of people if engineered right. I am
> trying to make a profiler include file which will be able to be used with
> one line of file.
>
>
>
> This will allow people to:
>
> . Get quick profiler results on demand by adding something to the
> query string - eg - ?profile=1
>
> . Get profile results for novices without having to mess around
> installing php binaries such as APD / zend debugger etc
>
> . Profile on demand on production servers without having to
install
> a resource intensive debugging module
>
>
>
> Any help greatly appreciated.
>
>
>
> Thanks,
>
>
>
> Scott McNaught
>
>
>
>
First off:

register_tick_function(array(&$pProfiler, 'tick'), true);

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

attached mail follows:

McNaught, Scott wrote:
> Hi Shawn,
>
> Thanks for the reply. I am using php5+ only, so I'm quite sure that passing
> the object by reference like that is done automatically.
>
> Aren't all objects are automatically passed by reference in php5, so
> therefore & is deprecated? I tested your suggestion anyway, and it appeared
> to make no difference.
>
> The problem is to do with the scope that the "declare" directive affects.
>
> Cheers anyway,
>
> Scott
>
> -----Original Message-----
> From: Shawn McKenzie [mailto:nospammckenzies.net]
> Sent: Friday, February 08, 2008 5:43 AM
> To: php-generallists.php.net
> Subject: [PHP] Re: Profiling with register_tick_function / declare
>
> McNaught, Scott wrote:
>> Hi there,
>>
>>
>>
>> Is it possible to make the declare(ticks=1) statement apply to *all*
>> functions executed in a php script, regardless of scope?
>>
>>
>>
>> I wish to write a profiler script to basically dump all the function call
>> times through the execution of a script. So far, I can only get it to
> work
>> for functions called via global scope.
>>
>>
>>
>> My code calls only one function from the global scope, and then a whole
> lot
>> of functions in classes are invoked. The tick function is only invoked
> once
>> from calling this one global function.
>>
>>
>>
>> Here is my code:
>>
>>
>>
>> <?php
>>
>> declare(ticks = 1);
>>
>>
>>
>> /**
>>
>> * Profiler
>>
>> *
>>
>> * version SVN: $Id$
>>
>> * author Scott McNaught
>>
>> */
>>
>> class Profiler
>>
>> {
>>
>> protected $m_arrProfileData = array();
>>
>> protected $m_strCurrentFunction = null;
>>
>> protected $m_iLastTime = null;
>>
>>
>>
>> /**
>>
>> * Begins profiling
>>
>> */
>>
>> public function start()
>>
>> {
>>
>> $this->m_iLastTime = time();
>>
>> }
>>
>>
>>
>> /**
>>
>> * Finishes profiling and dumps the results
>>
>> */
>>
>> public function end()
>>
>> {
>>
>> var_dump($this->m_arrProfileData);
>>
>> $this->m_arrProfileData = array();
>>
>> $this->m_strCurrentFunction = null;
>>
>> }
>>
>>
>>
>> public function tick()
>>
>> {
>>
>> $arrBacktrace = debug_backtrace();
>>
>>
>>
>> if (!isset($arrBacktrace[1]))
>>
>> {
>>
>> return;
>>
>> }
>>
>>
>>
>> $strFunction = $arrBacktrace[1]['function'];
>>
>>
>>
>> if (isset($arrBacktrace[1]['class']))
>>
>> {
>>
>> $strFunction = $arrBacktrace[1]['class'] . '::' .
>> $strFunction;
>>
>> }
>>
>>
>>
>> $iTime = microtime(true);
>>
>>
>>
>> if (!isset($this->m_arrProfileData[$strFunction]))
>>
>> {
>>
>> $this->m_arrProfileData[$strFunction] = $iTime;
>>
>> }
>>
>>
>>
>> $this->m_arrProfileData[$strFunction] += $iTime -
>> $this->m_iLastTime;
>>
>> $this->m_iLastTime = $iTime;
>>
>> $this->m_strCurrentFunction = $strFunction;
>>
>> }
>>
>> }
>>
>>
>>
>> $pProfiler = new Profiler();
>>
>> register_tick_function($pProfiler, 'tick'), true);
>>
>>
>>
>> ?>
>>
>>
>>
>>
>>
>> Then from index.php.
>>
>>
>>
>> <?php
>>
>>
>>
>> if(isset($_GET['profile']))
>>
>> {
>>
>> include('profiler.inc.php');
>>
>> }
>>
>>
>>
>> function execute()
>>
>> {
>>
>> $pClass = new SomeClass();
>>
>> $pClass->someFunction();
>>
>> }
>>
>>
>>
>> execute(); // TICK IS CALLED FROM EXECUTING THIS
>>
>>
>>
>> ?>
>>
>>
>>
>> So a tick is made from calling execute() from global scope, and that is
> it.
>> I want it to tick when someFunction() is called.
>>
>>
>>
>> I would really appreciate any help that anyone can give me with this as I
>> have struggled with it for a while, and there is not much documentation
>> about this anywhere.
>>
>> This could potentially benefit a lot of people if engineered right. I am
>> trying to make a profiler include file which will be able to be used with
>> one line of file.
>>
>>
>>
>> This will allow people to:
>>
>> . Get quick profiler results on demand by adding something to the
>> query string - eg - ?profile=1
>>
>> . Get profile results for novices without having to mess around
>> installing php binaries such as APD / zend debugger etc
>>
>> . Profile on demand on production servers without having to
> install
>> a resource intensive debugging module
>>
>>
>>
>> Any help greatly appreciated.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Scott McNaught
>>
>>
>>
>>
> First off:
>
> register_tick_function(array(&$pProfiler, 'tick'), true);
>
My point was the missing 'array(' in that statement.

The code seems to work for me if $pClass->someFunction() actually does
something. If it is empty it doesn't appear in the resulting profiler
array. For example, here is what I have that works:

<?php

$pProfiler->start();

function execute()
{
$pClass = new SomeClass();
$pClass->someFunction();
}

execute(); // TICK IS CALLED FROM EXECUTING THIS

$pProfiler->end();

class someClass
{
    public function someFunction()
    {
        echo "HELLO!";
    }
}

This shows:

HELLO!array(4) {
  ["include"]=>
  float(2404831569.3143)
  ["Profiler::start"]=>
  float(1202415785.3143)
  ["execute"]=>
  float(1202415784.6574)
  ["someClass::someFunction"]=>
  float(1202415784.6593)
}

But with an empty someFunction() I get:

array(3) {
  ["include"]=>
  float(2404831928.8424)
  ["Profiler::start"]=>
  float(1202415964.8424)
  ["execute"]=>
  float(1202415964.4215)
}

attached mail follows:

Hmmm... Also:

This works:

public function someFunction()
    {
        $a++;
    }

This does not:

public function someFunction()
    {
        return $a++;
    }

attached mail follows:

Right I understand the problem I have been experiencing now.

1) Functions that return something do not work
2) APC and ticks do not mix - I needed to restart the web server to get it
to work

If you have apc installed, try making changes to your src. Ie - adding new
calls to different functions. They aren't invoked on ticks.

I don't think these ticks can be relied upon - a neat idea but they don't
seem to be implemented right yet.

Scott

-----Original Message-----
From: Shawn McKenzie [mailto:nospammckenzies.net]
Sent: Friday, February 08, 2008 6:34 AM
To: php-generallists.php.net
Subject: Re: [PHP] Re: Profiling with register_tick_function / declare

McNaught, Scott wrote:
> Hi Shawn,
>
> Thanks for the reply. I am using php5+ only, so I'm quite sure that
passing
> the object by reference like that is done automatically.
>
> Aren't all objects are automatically passed by reference in php5, so
> therefore & is deprecated? I tested your suggestion anyway, and it
appeared
> to make no difference.
>
> The problem is to do with the scope that the "declare" directive affects.
>
> Cheers anyway,
>
> Scott
>
> -----Original Message-----
> From: Shawn McKenzie [mailto:nospammckenzies.net]
> Sent: Friday, February 08, 2008 5:43 AM
> To: php-generallists.php.net
> Subject: [PHP] Re: Profiling with register_tick_function / declare
>
> McNaught, Scott wrote:
>> Hi there,
>>
>>
>>
>> Is it possible to make the declare(ticks=1) statement apply to *all*
>> functions executed in a php script, regardless of scope?
>>
>>
>>
>> I wish to write a profiler script to basically dump all the function call
>> times through the execution of a script. So far, I can only get it to
> work
>> for functions called via global scope.
>>
>>
>>
>> My code calls only one function from the global scope, and then a whole
> lot
>> of functions in classes are invoked. The tick function is only invoked
> once
>> from calling this one global function.
>>
>>
>>
>> Here is my code:
>>
>>
>>
>> <?php
>>
>> declare(ticks = 1);
>>
>>
>>
>> /**
>>
>> * Profiler
>>
>> *
>>
>> * version SVN: $Id$
>>
>> * author Scott McNaught
>>
>> */
>>
>> class Profiler
>>
>> {
>>
>> protected $m_arrProfileData = array();
>>
>> protected $m_strCurrentFunction = null;
>>
>> protected $m_iLastTime = null;
>>
>>
>>
>> /**
>>
>> * Begins profiling
>>
>> */
>>
>> public function start()
>>
>> {
>>
>> $this->m_iLastTime = time();
>>
>> }
>>
>>
>>
>> /**
>>
>> * Finishes profiling and dumps the results
>>
>> */
>>
>> public function end()
>>
>> {
>>
>> var_dump($this->m_arrProfileData);
>>
>> $this->m_arrProfileData = array();
>>
>> $this->m_strCurrentFunction = null;
>>
>> }
>>
>>
>>
>> public function tick()
>>
>> {
>>
>> $arrBacktrace = debug_backtrace();
>>
>>
>>
>> if (!isset($arrBacktrace[1]))
>>
>> {
>>
>> return;
>>
>> }
>>
>>
>>
>> $strFunction = $arrBacktrace[1]['function'];
>>
>>
>>
>> if (isset($arrBacktrace[1]['class']))
>>
>> {
>>
>> $strFunction = $arrBacktrace[1]['class'] . '::' .
>> $strFunction;
>>
>> }
>>
>>
>>
>> $iTime = microtime(true);
>>
>>
>>
>> if (!isset($this->m_arrProfileData[$strFunction]))
>>
>> {
>>
>> $this->m_arrProfileData[$strFunction] = $iTime;
>>
>> }
>>
>>
>>
>> $this->m_arrProfileData[$strFunction] += $iTime -
>> $this->m_iLastTime;
>>
>> $this->m_iLastTime = $iTime;
>>
>> $this->m_strCurrentFunction = $strFunction;
>>
>> }
>>
>> }
>>
>>
>>
>> $pProfiler = new Profiler();
>>
>> register_tick_function($pProfiler, 'tick'), true);
>>
>>
>>
>> ?>
>>
>>
>>
>>
>>
>> Then from index.php.
>>
>>
>>
>> <?php
>>
>>
>>
>> if(isset($_GET['profile']))
>>
>> {
>>
>> include('profiler.inc.php');
>>
>> }
>>
>>
>>
>> function execute()
>>
>> {
>>
>> $pClass = new SomeClass();
>>
>> $pClass->someFunction();
>>
>> }
>>
>>
>>
>> execute(); // TICK IS CALLED FROM EXECUTING THIS
>>
>>
>>
>> ?>
>>
>>
>>
>> So a tick is made from calling execute() from global scope, and that is
> it.
>> I want it to tick when someFunction() is called.
>>
>>
>>
>> I would really appreciate any help that anyone can give me with this as I
>> have struggled with it for a while, and there is not much documentation
>> about this anywhere.
>>
>> This could potentially benefit a lot of people if engineered right. I am
>> trying to make a profiler include file which will be able to be used with
>> one line of file.
>>
>>
>>
>> This will allow people to:
>>
>> . Get quick profiler results on demand by adding something to the
>> query string - eg - ?profile=1
>>
>> . Get profile results for novices without having to mess around
>> installing php binaries such as APD / zend debugger etc
>>
>> . Profile on demand on production servers without having to
> install
>> a resource intensive debugging module
>>
>>
>>
>> Any help greatly appreciated.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Scott McNaught
>>
>>
>>
>>
> First off:
>
> register_tick_function(array(&$pProfiler, 'tick'), true);
>

Hmmm... Also:

This works:

public function someFunction()
    {
        $a++;
    }

This does not:

public function someFunction()
    {
        return $a++;
    }

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

attached mail follows:

McNaught, Scott schreef:
> Hi there,
>
>
>
> Is it possible to make the declare(ticks=1) statement apply to *all*
> functions executed in a php script, regardless of scope?
>

is the declare() pragma not a file scope wotsit? i.e. you'd have to
do declare(ticks=1); at the top of each file.

...

>
> . Get profile results for novices without having to mess around
> installing php binaries such as APD / zend debugger etc

I suppose that includes xdebug?

>
> . Profile on demand on production servers without having to install
> a resource intensive debugging module

does profiling need to be done in production at all? slow code is slow however you
look at it no? so profiling something in a dev environment should show just as
much info as anywhere else?

>
>
>
> Any help greatly appreciated.
>
>
>
> Thanks,
>
>
>
> Scott McNaught
>
>
>
>

attached mail follows:

On Feb 7, 2008 7:10 PM, Jochem Maas <jochemiamjochem.com> wrote:
> McNaught, Scott schreef:
> > . Get profile results for novices without having to mess around
> > installing php binaries such as APD / zend debugger etc
>
> I suppose that includes xdebug?

If xdebug works as a local binary (which it may, I'm not sure),
you'd still have to have a local php.ini and be allowed to override
the server php.ini by configuration, no?

What if both of the above are true, but a user has no permissions
to compile?

While I was going to point out this morning that he failed to
mention xdebug (which is my personal favorite), I still wouldn't
discount his script-based profiler, if he can get it to work. Imagine
being able to drop that into a project on SourceForge.

--
</Dan>

Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>

attached mail follows:

On 2/7/08, Richard Heyes <richardhphpguru.org> wrote:
> > http://www.phprecovery.com/
>
> Pointless? I think it is exactly the answer to the original persons
> question.

Yup, it's the exact correct answer, to a pointless question.

Even Zend knows it's pointless to encode PHP. When you type "decode
php" into Google you see ads for the Zend Encoder. Does that tell you
anything?

Encoding PHP, or licensing it, or compiling it to an extension, or any
other silly obfuscation ideas you come up with, in the end, only keeps
an honest person honest. If someone wants to reverse code that you
have put in their possession, they will find a way.

Deductive reasoning leads to two possible options:

1) Don't give the code to anyone.
2) Give the code to the client and accept the fact that it may get pirated.

--
Greg Donald
http://destiney.com/

attached mail follows:

On Feb 7, 2008 4:56 PM, Greg Donald <gdonaldgmail.com> wrote:
> On 2/7/08, Richard Heyes <richardhphpguru.org> wrote:
> > > http://www.phprecovery.com/
> >
> > Pointless? I think it is exactly the answer to the original persons
> > question.
>
> Yup, it's the exact correct answer, to a pointless question.
>
> Even Zend knows it's pointless to encode PHP. When you type "decode
> php" into Google you see ads for the Zend Encoder. Does that tell you
> anything?

Actually, Greg, I respectfully disagree. First, just because
there may be ways to reverse-engineer things doesn't mean it's a bad
idea to attempt to protect your code against such. I know that people
can smash in the windows of my Durango and steal my equipment, but I
still lock it when I park it and go into the store. Why? Because I
don't want to make things easy enough for someone to be tempted to
take something. I know that if they want something badly enough,
they'll take it.... but I'm just not going to make it that easy.

And if Zend considered it "pointless", they probably would no
longer attempt to further develop - nor put their name on the line to
sell - the product line. By definition, pointless means "Lacking
meaning; senseless. Ineffectual: pointless attempts to rescue the
victims of the raging fire."[1] I fail to see the correlation here;
Zend is aware that there are ways to decode their method of
obfuscation (any and all are trivial, really), but admitting defeat is
failure in this case. That, in my opinion, is pointless.

> Encoding PHP, or licensing it, or compiling it to an extension, or any
> other silly obfuscation ideas you come up with, in the end, only keeps
> an honest person honest. If someone wants to reverse code that you
> have put in their possession, they will find a way.

It also keeps script kiddies from typing "decode php" into Google
and being able to pull one over. While industry standards may not be
the lock that cannot be picked, proprietary obfuscation will keep
people who don't know what they're doing out of your code --- and if
they possess the acumen and free time to be able to reverse-engineer
the code themselves, I honestly don't know why they'd pay someone to
develop the application in PHP for them in the first place.

> Deductive reasoning leads to two possible options:
>
> 1) Don't give the code to anyone.
> 2) Give the code to the client and accept the fact that it may get pirated.

I completely agree with you here. I'll also add the same thing I
always tell people when they ask me about security: any time there is
a way to connect to a device over the wire or otherwise, the data will
never be secure.

That stands for ASP (Application Service Providers, in this case -
the only *decent* ASP there is! ;-P) as well.

[1] - http://www.answers.com/pointless&r=67

--
</Dan>

Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>

attached mail follows:

On 2/7/08, Daniel Brown <parasanegmail.com> wrote:
> Actually, Greg, I respectfully disagree. First, just because
> there may be ways to reverse-engineer things doesn't mean it's a bad
> idea to attempt to protect your code against such.

Why would you encode to start with? The only reason I can think of is
because you don't trust your client. So why are you doing business
with people you don't trust?

> I know that people
> can smash in the windows of my Durango and steal my equipment, but I
> still lock it when I park it and go into the store. Why? Because I
> don't want to make things easy enough for someone to be tempted to
> take something. I know that if they want something badly enough,
> they'll take it.... but I'm just not going to make it that easy.

That's my whole point. Honest people aren't gonna steal your code
anyway. Trying to prevent them from making a simple change when
you're not around is pointless.

Would you have bought that Durango if the hood had been welded shut?
I'm guessing you're not a mechanic, so you'll _never_ need to raise
the hood, right? What about when you come out of the grocery store
and there's a hot blonde who needs a jump because she forgot and left
her lights on before she went in?

> And if Zend considered it "pointless", they probably would no
> longer attempt to further develop - nor put their name on the line to

Oh please, Zend isn't the first company to ever create useless
software. Creation, in no way, proves usefulness.

> sell - the product line. By definition, pointless means

I know where dictionary.com is, thanks :)

> It also keeps script kiddies from typing "decode php" into Google
> and being able to pull one over.

I fail to see how Zend adding "decode" into their list of Google
Adwords keeps script kiddies from doing anything. I used the Google
Adwords example as confirmation Zend is well aware of existing
decoders.

> While industry standards may not be
> the lock that cannot be picked, proprietary obfuscation will keep
> people who don't know what they're doing out of your code --- and if

If you're paid to write code then write code, and then when you're
done give them the code and collect your money. They paid for the
code so why do you think you still own rights to it?

> they possess the acumen and free time to be able to reverse-engineer
> the code themselves, I honestly don't know why they'd pay someone to
> develop the application in PHP for them in the first place.

I honestly don't know where you find clients so dumb that they who
would put up with not getting full source code for a paid project.

--
Greg Donald
http://destiney.com/

attached mail follows:

On Feb 7, 2008 6:20 PM, Greg Donald <gdonaldgmail.com> wrote:
> On 2/7/08, Daniel Brown <parasanegmail.com> wrote:
> > Actually, Greg, I respectfully disagree. First, just because
> > there may be ways to reverse-engineer things doesn't mean it's a bad
> > idea to attempt to protect your code against such.
>
> Why would you encode to start with? The only reason I can think of is
> because you don't trust your client. So why are you doing business
> with people you don't trust?

Because who's to say you're selling to one client? If it's your
Intellectual Property, wouldn't you want to protect it, at least as
much as possible?

> > I know that people
> > can smash in the windows of my Durango and steal my equipment, but I
> > still lock it when I park it and go into the store. Why? Because I
> > don't want to make things easy enough for someone to be tempted to
> > take something. I know that if they want something badly enough,
> > they'll take it.... but I'm just not going to make it that easy.
>
> That's my whole point. Honest people aren't gonna steal your code
> anyway. Trying to prevent them from making a simple change when
> you're not around is pointless.

No, but it does allow for a better contract stating something
along the lines of, "in order to maintain a valid warranty, all
updates must be done by Company XYZ, at a fee of $n." However, I'll
agree to the point that, if you're selling something once-off to a
client, then it's ludicrous to encode the software. However, it still
doesn't make the practice of encoding "pointless."

> Would you have bought that Durango if the hood had been welded shut?
> I'm guessing you're not a mechanic, so you'll _never_ need to raise
> the hood, right? What about when you come out of the grocery store
> and there's a hot blonde who needs a jump because she forgot and left
> her lights on before she went in?

That's like comparing apples to vaginas. There's no similarity
between the two unless you *really* look for it and make a lot of
concessions. I may never need to look under the hood, but a qualified
mechanic - as so designated in the vehicle owner's manual, contract,
and warranty specifications (relate this to my first paragraph) - will
need access to the engine compartment. In my case, it would be the
dealer --- who is employed by the manufacturer of the code --- err,
car. ;-P

And if that hot blonde is there, I'll ask first if she likes apples.

> > And if Zend considered it "pointless", they probably would no
> > longer attempt to further develop - nor put their name on the line to
>
> Oh please, Zend isn't the first company to ever create useless
> software. Creation, in no way, proves usefulness.

Exactly. Humankind is a perfect example. Nonetheless, now you're
going on a separate tangent.

> > sell - the product line. By definition, pointless means
>
> I know where dictionary.com is, thanks :)

Cool. I wasn't sure, because I thought you'd have used it prior
to using the term "pointless" incorrectly. ;-P (Note: my smartass
remarks are only joking around, I'm not attacking you in any way. I
just really enjoy a debate.)

> > It also keeps script kiddies from typing "decode php" into Google
> > and being able to pull one over.
>
> I fail to see how Zend adding "decode" into their list of Google
> Adwords keeps script kiddies from doing anything. I used the Google
> Adwords example as confirmation Zend is well aware of existing
> decoders.

Yes, and I used the same phrase for searching as an example of for
what even a low-level "cracker" would first search. It doesn't mean
that Zend is or isn't aware of the existence. So this part, to me,
seems baseless and unrelated to the overall discussion, but feel free
to re-explain if my brain isn't grabbing hold properly.

> > While industry standards may not be
> > the lock that cannot be picked, proprietary obfuscation will keep
> > people who don't know what they're doing out of your code --- and if
>
> If you're paid to write code then write code, and then when you're
> done give them the code and collect your money. They paid for the
> code so why do you think you still own rights to it?

    Again, I agree wholeheartedly, save for two situations:
        1.) Multiple customers, such as an off-the-shelf script being sold.
        2.) Contract retention. While the document should legally
protect your interests, your adding *A BENEFIT* to your product for
the client: deniability. If a huge bug is discovered in your scripts
that costs the client $10,000, they can turn around and say, "well, we
didn't touch the code because we couldn't, so the bug was already
there." However, with that risk comes the benefit of being granted
exclusive contracts for continued support on the scripts.

> > they possess the acumen and free time to be able to reverse-engineer
> > the code themselves, I honestly don't know why they'd pay someone to
> > develop the application in PHP for them in the first place.
>
> I honestly don't know where you find clients so dumb that they who
> would put up with not getting full source code for a paid project.

Hopefully by now I've illustrated enough points. For now, I'm
heading out of the office for the evening.

Well, at least that's the plan at this moment....

--
</Dan>

Daniel P. Brown
Senior Unix Geek
<? while(1) { $me = $mind--; sleep(86400); } ?>

attached mail follows:

> -----Original Message-----
> From: Daniel Brown [mailto:parasanegmail.com]
> Sent: Thursday, February 07, 2008 7:10 PM
> To: Greg Donald
> Cc: php-generallists.php.net
> Subject: Re: [PHP] PHP Source code protection
>
> On Feb 7, 2008 6:20 PM, Greg Donald <gdonaldgmail.com> wrote:
> > On 2/7/08, Daniel Brown <parasanegmail.com> wrote:
> > > Actually, Greg, I respectfully disagree. First, just because
> > > there may be ways to reverse-engineer things doesn't mean it's a bad
> > > idea to attempt to protect your code against such.
> >
> > Why would you encode to start with? The only reason I can think of is
> > because you don't trust your client. So why are you doing business
> > with people you don't trust?
>
> Because who's to say you're selling to one client? If it's your
> Intellectual Property, wouldn't you want to protect it, at least as
> much as possible?
>
> > > I know that people
> > > can smash in the windows of my Durango and steal my equipment, but I
> > > still lock it when I park it and go into the store. Why? Because I
> > > don't want to make things easy enough for someone to be tempted to
> > > take something. I know that if they want something badly enough,
> > > they'll take it.... but I'm just not going to make it that easy.
> >
> > That's my whole point. Honest people aren't gonna steal your code
> > anyway. Trying to prevent them from making a simple change when
> > you're not around is pointless.
>
> No, but it does allow for a better contract stating something
> along the lines of, "in order to maintain a valid warranty, all
> updates must be done by Company XYZ, at a fee of $n." However, I'll
> agree to the point that, if you're selling something once-off to a
> client, then it's ludicrous to encode the software. However, it still
> doesn't make the practice of encoding "pointless."
>
> > Would you have bought that Durango if the hood had been welded shut?
> > I'm guessing you're not a mechanic, so you'll _never_ need to raise
> > the hood, right? What about when you come out of the grocery store
> > and there's a hot blonde who needs a jump because she forgot and left
> > her lights on before she went in?
>
> That's like comparing apples to vaginas. There's no similarity
> between the two unless you *really* look for it and make a lot of
> concessions. I may never need to look under the hood, but a qualified
> mechanic - as so designated in the vehicle owner's manual, contract,
> and warranty specifications (relate this to my first paragraph) - will
> need access to the engine compartment. In my case, it would be the
> dealer --- who is employed by the manufacturer of the code --- err,
> car. ;-P
>
> And if that hot blonde is there, I'll ask first if she likes apples.
>
>
> > > And if Zend considered it "pointless", they probably would no
> > > longer attempt to further develop - nor put their name on the line to
> >
> > Oh please, Zend isn't the first company to ever create useless
> > software. Creation, in no way, proves usefulness.
>
> Exactly. Humankind is a perfect example. Nonetheless, now you're
> going on a separate tangent.
>
> > > sell - the product line. By definition, pointless means
> >
> > I know where dictionary.com is, thanks :)
>
> Cool. I wasn't sure, because I thought you'd have used it prior
> to using the term "pointless" incorrectly. ;-P (Note: my smartass
> remarks are only joking around, I'm not attacking you in any way. I
> just really enjoy a debate.)
>
> > > It also keeps script kiddies from typing "decode php" into Google
> > > and being able to pull one over.
> >
> > I fail to see how Zend adding "decode" into their list of Google
> > Adwords keeps script kiddies from doing anything. I used the Google
> > Adwords example as confirmation Zend is well aware of existing
> > decoders.
>
> Yes, and I used the same phrase for searching as an example of for
> what even a low-level "cracker" would first search. It doesn't mean
> that Zend is or isn't aware of the existence. So this part, to me,
> seems baseless and unrelated to the overall discussion, but feel free
> to re-explain if my brain isn't grabbing hold properly.
>
> > > While industry standards may not be
> > > the lock that cannot be picked, proprietary obfuscation will keep
> > > people who don't know what they're doing out of your code --- and if
> >
> > If you're paid to write code then write code, and then when you're
> > done give them the code and collect your money. They paid for the
> > code so why do you think you still own rights to it?
>
> Again, I agree wholeheartedly, save for two situations:
> 1.) Multiple customers, such as an off-the-shelf script being sold.
> 2.) Contract retention. While the document should legally
> protect your interests, your adding *A BENEFIT* to your product for
> the client: deniability. If a huge bug is discovered in your scripts
> that costs the client $10,000, they can turn around and say, "well, we
> didn't touch the code because we couldn't, so the bug was already
> there." However, with that risk comes the benefit of being granted
> exclusive contracts for continued support on the scripts.
>
> > > they possess the acumen and free time to be able to reverse-engineer
> > > the code themselves, I honestly don't know why they'd pay someone to
> > > develop the application in PHP for them in the first place.
> >
> > I honestly don't know where you find clients so dumb that they who
> > would put up with not getting full source code for a paid project.
>
> Hopefully by now I've illustrated enough points. For now, I'm
> heading out of the office for the evening.
>
> Well, at least that's the plan at this moment....
>
> --
> </Dan>
>
> Daniel P. Brown
> Senior Unix Geek
> <? while(1) { $me = $mind--; sleep(86400); } ?>

Has anybody mentioned ionCube? http://www.ioncube.com/ It's always the choice
for encoding DirectAdmin commercial templates and plugins (not saying it is the
best, just the common practice in DA's commercial world).

Also:
1 - I believe the fact that we don't "encode" (read "compile") our scripts is
tightly related to the fact that we don't have a bytecode interpreter (say JIT
compiler or something?) bundled into PHP. If we had, we'd all release the
compiled scripts for "performance" reasons and "forget" about distributing the
source code (clients don't usually ask for source code, they usually don't even
know what source code is). So, we don't encode them, compile them, "binarize"
them because we can't rely on anything installed in hosting XYZ. Existing "pure
PHP" obfuscating solutions are not worth the try (my opinion) and only
compromise performance or break working code (my opinion again).
2 - Decoding an encoded script will not (usually?) restore the "original source
code", but rather a "reverse engineered binary code" that would become the
encoded script if it was again processed by the encoding software. So, if source
code alone is hard to read sometimes, just imagine "reverse engineered binary
code". So, I think that encoding PHP scripts for copyright, security, or
whatever reason, is as valid as using serial numbers and activation codes for
desktop software, despite we all know that we can get key generators and cracks
in the p2p networks, such as ed2k and bittorrent.
3 - If the PHP license allows for commercial use of PHP scripts and allows for
encoding the sources, I don't see any compelling reason or commandment to not do
so. If you give away something, nobody has the obligation of doing the same. It
is the client who has to make the choice; and other than that, it is you who
have to either start encoding your files or placing huge banners in your site
with the phrase "WE DON'T ENCODE OUR WORK", or just do nothing.

Just to make it clear, we don't encode our work :), but only because:
1 - We trust ourselves, that nobody can get a better deal for our clients.
2 - If we offered source release as an extra, no client would want it and it
would still be a management pain for us to debug->encode->upload. The only
concern for a client is that "the damn thing works". If "the damn thing doesn't
work" they would just contract someone else, source code or not. It doesn't make
any difference.
3 - Either you have to buy encoding software and beg all your clients have the
"decoding" counterpart installed in their servers, or force all your development
clients to host with you, or you have to use pure PHP solutions, which all have
some performance hit.

But even trusting ourselves, we don't release the source code until the last
cent of a project is paid. In the meantime, we host the project. We don't have
to trust the client 100%, and that's why we all sign contracts and lawyers
exist. In business you can be very friendly and complaisant with your clients;
but the only thing you can (barely) trust is a signed piece of paper reviewed by
a lawyer. Don't misunderstand me, some clients are great to work with, even
those who come to you with "cutting-edge" ideas for which you spend a weekend
without seeing sunshine. But there are some who just "change their minds" about
a critical point in the middle of a project and will want you to rewrite the
whole thing from scratch threatening you that they will go somewhere else
without paying you a cent (there are people like this).
All in all, encoding is either a critical thing, or just another link in the
chain, but it is as valid as compiling a C# application and some people may have
very specific needs to do so.

Regards,

Rob

attached mail follows:

On 2/6/08, Leonard Burton <leonardburtongmail.com> wrote:
> Is there an OS program that will take a url and crawl/cache all the links on it?

`wget -m -np http://example.com` will mirror the url and anything under it.

That's '-m' for mirror, and '-np' for no parent.. so you don't
download the whole internet.

--
Greg Donald
http://destiney.com/

attached mail follows:

Hello,

on 02/07/2008 01:52 PM Nathan Nobbe said the following:
>> What happens is that Propel relies on fat base classes that the
>> generated persistent object classes need to inherit to do the actual
>> Object-relational mapping.
>
> this is so that there is a customizable layer that will not be impacted by
> subsequent regeneration. qcodo has the same concept and i suspect
> doctrine does as well.

My point is that the base classes are not needed and only lead to less
efficient code. They carry all sorts of functionality that you may ever
need in all possible persistent classes, but in reality each individual
class only needs a fraction of the functionality.

> Metastorage generates self-contained code. This means the generated
>> classes are root classes that do only what you need.
>
>
> Then they must themselves be 'fat'; using inheritance to encapsulate common
> functionality is obviously a sound technique.

You need to check the actual generated code before you can reach your
conclusions.

What happens is Metastorage anticipates many decisions to the compile
time. It makes static optimizations based on things that will not change
at run time.

For instance, the list of class variables mapped to database table
fields does not change at run time until you do not upgrade your model.
Therefore, Metastorage generates SQL queries at compile time that
include static lists of fields or query condition clauses. There is no
need to waste time recomputing the list of fields or rebuilding query
conditions at run-time.

This is just an example of static compile time code generation
optiomizations. It makes many others based on the knowlegde of things
that won't change at run-time.

>> The generated code
>> does the necessary database calls directly to store and retrieve objects.
>
>
> So does propel.

That is not what I understood from last time I talked with Hans. I have
yet to see an working example but Propel does not seem to come with one.
Also the installation of Propel and all dependent tools is a bit
complicated and discouraging for me to try and see what you are talking
about.

>> It does not call base classes like Propel generated classes that waste
>> time composing SQL queries at run-time. Metastorage generated classes
>> already have the necessary SQL built-in to execute the queries without
>> further analysis at run-time.
>
>
> It has *all* the necessay sql embedded in it? i find this hard to believe.
> say
> for example i run a query without a limit clause; then i want to run the
> same
> query with a limit clause; it is simply impractical to pre-write 2 queries,
> one
> with a limit clause and one without it into the code at compile time.
> moreover
> i sincerely doubt this is the approach theyve taken because if you just sit
> and
> think about it for a second, with even a small number of tables the
> permutations
> on the set of all possible queries would be staggering. such classes that
> would
> encapsulate said number of permutations would be way beyond 'fat',
> i would imagine. so im guessing metastorage does some sort of query
> composition at runtime.

No, that is not what I mean. Of course Metastorage generated code needs
to concatenate parts of SQL strings, especially when you have values
that are only defined at run-time.

But for instance, if you need to query an object with a given condition,
Metastorage provide an Object Query Language (OQL) that lets you express
conditions. Metastorage compiles the conditions and generates PHP string
expressions that you just need to concatenate at run time with the rest
of the SQL SELECT statement. There is no waste of time and code
composing the condition clause at run-time.

>> Another aspect is that Metastorage features what is called report
>> classes. These are classes that perform queries that you define and
>> generates SQL and PHP at compile time to retrieve data from the
>> persistent objects for read-only purposes.
>
>
> so you save some time building queries at runtime for special cases;
> thats kind of nice; but i dont think it takes much time to actually build
> a query anyway.

It is not just time, it is also code that you have to write to compose
and build queries at run-time before executing. Since SQL queries that
you will execute do not change at run-time, Metastorage generates the
query clauses at compile time so you do not waste time and additional
code to have the queries built by your application before executing.

> For instance, if you want to send a newsletter to a million subscribers
>> and you just need the e-mail address and names of the subscribers, you
>> can tell Metastorage to generate a report class that queries the users
>> objects and retrives just the name and e-mail address. The report
>> classes return arrays just like plain SELECT queries.
>
>
> thats great, arrays are a little more lean than objects; but obviously they
> are not wrapped with any additional functionality; such as the ability to
> fetch
> the value of a record in a related table or alter the current value.

No, that is not the point. An object of a class may have tens of
variables (or properties if you prefer to call them that way). However,
to send a newsletter, you just need 2. Why are you going to retrieve all
class variables if you just need 2?

Another detail, if your newsletter needs values from multiple classes,
you need to query objects of the different classes envolved.

With Metastorage report classes, I just call a function and get Just
Exactly What I Need - JE WIN approach. Not more, not less. It just does
what would do if I were not using an ORM tool, a simple select call with
eventual joins, conditions, sorting, aggregation, pagination, etc...

It would be pointless to use persistent classes for these purposes
because you just need to retrieve data for read-only purposes. No
objects are updated when you need to generate reports or send
newsletters for instance.

>> If you use the Propel approach you would need to retrieve 1 million
>> objects of the users class just to pick the name and e-mail address,
>> which is totally inefficient in terms of memory and very slow.
>
>
> well lets just remember that even though arrays are just data and therefore
> less expensive in terms of memory and quicker to iterate; there would still
> be 1 million arrays of data.

Of course not, you can just retrieve one array at a time.

Still, even if you retrieve 1 million arrays to memory with just two
elements (name and e-mail), it takes much less memory than retrieving
millions of objects with all class variables including all those that
you do not need.

>> There are more differences between Metastorage and Propel (and probably
>> others approach). I just wanted to make the point that the fact that
>> approaches use generated code, it does not mean that all provide the
>> same efficiency.
>
>
> i would like to see some benchmarks of propel vs. metastorage. i would do
> them myself except that i simply dont have time to do a proper experiment in
> the near future. i will certainly consider an analysis of metastorage for a
> rainy
> day though.

Sorry, you may perform any benchmarks you want, but competition is not
my point here. I am just exchanging opinions and points of views.

There are ORM tools that are younger and eventually less mature. Their
developers may just learn from the benefits that other more mature ORM
tools provide.

I started Metastorage in 2002 and have analyzed several ORM approaches
before I figured what to do that to make an ORM tool that generates
satisfactory code as if I would write manually if I had too.

Of course, I am not assuming Metastorage provides the best solution in
all aspects. There is plenty of room for improvement in Metastorage, so
it is also beneficial to demonstrate if other approaches can provide
better results than Metastorage approach.

Regards,
Manuel Lemos

PHP professionals looking for PHP jobs
http://www.phpclasses.org/professionals/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/

attached mail follows:

On 2/6/08, Nathan Nobbe <quickshiftingmail.com> wrote:
> ruby on rails as one of these obfusticators of fowlers original pattern;

I don't see how code generation could ever be worse (slower) than
runtime analysis. Sure you have to hit the database once to know what
the fields are, but after that your overhead drops to only include
whatever generated code you made from your fields knowledge.

The Rails ActiveRecord implementation _does it all_ I can tell you.
I'm using (and reversing parts of it where required) to build out a
generic database admin tool. Have a look:

http://railsdb.org/

At this point I've successfully hooked it up to Oracle, MySQL,
PostgreSQL, and SQLite.

> greg, thoughts ?

I like pie.

Martin Fowler +1, if you're a software developer and don't own any
books by him, you should.

--
Greg Donald
http://destiney.com/

attached mail follows:

Daniel Brown schreef:
> On Feb 7, 2008 8:34 AM, Jochem Maas <jochemiamjochem.com> wrote:
>> Martin Marques schreef:
>>>> see what you have as the value for the date.timezone ini setting.
>>> I've already checked that, and it's not set.
>> it should be set to something, so fix that.
>
> All other points being valid, Jochem, I disagree with this. I've
> never forced a setting on any of my PHP installations, and so far
> (knock on wood) I've never had a problem. I think PHP does a fine job
> of reading the server time and zone.

most likely, personally I set it in code as required. I was reiterating what
the author of the new datetime stuff has repeated on a number of occasions,
namely that your application or php.ini file should be settingthe value to
something suitable explicitly.

how valid this actually is obviously open to question, besides date/time
issues will probably be one of those horrid things that will keep on biting
people in the *** no? calendars, timezones and everything related is just
too finickity :)

attached mail follows:

Hi,

How can I parse this kind of XML data?

<event:event>

< event:sessionType>9</event:sessionType>

<event:hostWebExID>marketingprograms</event:hostWebExID>

<event:startDate>05/22/2008 09:00:00</event:startDate>

<event:endDate>05/22/2008 10:00:00</event:endDate>

<event:timeZoneID>4</event:timeZoneID>

<event:duration>60</event:duration>
</event:event>

I am using SimpleXMLElement function but some cannot retrieve the
nodes like timeZoneID for example

Thanks

attached mail follows:

On Feb 7, 2008 6:17 PM, VamVan <vamseevangmail.com> wrote:

> Hi,
>
> How can I parse this kind of XML data?
>
> <event:event>
>
>
> < event:sessionType>9</event:sessionType>
>
> <event:hostWebExID>marketingprograms</event:hostWebExID>
>
> <event:startDate>05/22/2008 09:00:00</event:startDate>
>
> <event:endDate>05/22/2008 10:00:00</event:endDate>
>
> <event:timeZoneID>4</event:timeZoneID>