Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:32155
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daleenterprise.com from 67.78.11.229 cause and error)
In-Reply-To: <46E4CF9F.2050305@liip.ch>
References: <EFA8CE6B-BA11-47F0-BA27-AC3BBCF42F32@daleenterprise.com> <46E4CB0B.4050700@liip.ch> <995233DC-EF1C-4EB8-979F-9FEDD82FAA1C@daleenterprise.com> <46E4CF9F.2050305@liip.ch>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <CC40E475-1E83-45D3-AB59-B1D8A58B27F4@daleenterprise.com>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Mon, 10 Sep 2007 01:31:54 -0400
To: Christian Stocker <christian.stocker@liip.ch>
MTA-Interface: amavisd-new-2.3.3 (2005-08-22) + Maia Mailguard 1.1.0 at daleenterprise.com
Subject: Re: [PHP-DEV] rfc1867.c compatibility question [closed]
From: buildsmart@daleenterprise.com (BuildSmart)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On Sep 10, 2007, at 01:01:19, Christian Stocker wrote:

>
>
> On 10.9.2007 6:53 Uhr, BuildSmart wrote:
>>
>> On Sep 10, 2007, at 24:41:47, Christian Stocker wrote:
>>
>>
>>
>>> On 10.9.2007 3:53 Uhr, BuildSmart wrote:
>>>> I was asked to look into the pdoru patch and extension by a  
>>>> client, this
>>>> is where I noticed that a similar patch is already applied to the
>>>> rfc1867.c file
>>>> (http://cvs.php.net/viewvc.cgi/php-src/main/rfc1867.c? 
>>>> r1=1.173.2.1&r2=1.173.2.1.2.1&pathrev=PHP_5_2&view=patch),
>>>>
>>>> is this patch compatible with the pdoru Upload Progress Meter  
>>>> extension
>>>> or do I need to write something from scratch?
>>
>>> http://pecl.php.net/package/uploadprogress
>>
>> Ok so after examination of this extension it looks like it's  
>> basically
>> using the same code with the exception of no support for memcache
>
> from
>
> http://pdoru.from.ro/upload-progress-meter/upload-progress-meter- 
> v4.1/upload_progress_meter/upload_progress_meter.c
>
> static int mmcache_loaded(void) { return 0; }
> static void * callback_mmcache( void *pointer, int read_bytes, int
> total_bytes, int what_happened )
> {
>    return NULL;
> }
>
> Doesn't look like much support for m(e)mcache :)

Yes but that isn't the code I'm using, he started it and never  
completed it, the basic code is there but he never completed the  
memcache required functions, I've filled in the missing memcache code  
in the version I have, if it's not compatible with his basic  
extension then I either need to code from scratch or modify the pecl  
extension to support it and this is what I'm tyring to determine.

>
>
>> and
>> this is a requirement but my question was, is the provided patch
>> compatible with the pdoru extension (the pdoru extension works  
>> properl)?
>
> I don't know exactly, but I don't think, that it's 100% compatible,
> there was a reason for the PECL extension...

Due to your remark I built it using my version of the pdoru code and  
ran a few simple tests, you are correct it's not 100% compatible, it  
has arbitrary issues validating the identifier and thus believes the  
identifier is invalid which in turn cancels the upload, only 1 out of  
7 succeeded.

I tested in file mode only and saw no need to test the memcache code  
due to the high failure rate.

In light of this I think my best bet is to take the pecl extension  
code and add my memcache routines to satisfy my client.

Now since the code is somewhat similar in design with some minor  
changes, mainly flow-control, I'm wondering how stable the extension  
is but since it's in pecl one might conclude that it's fairly stable/ 
dependable or is this a poor assumption?

Thanks for pointing me in the right direction, I'll run some cursory  
tests with the pecl extension before going any further.

>
> chregu

- -- Dale


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)

iD8DBQFG5NbL0hzWbkf0eKgRArKNAKCkLjg3fKC3RQ3T7OIVaNYmkLXJ/QCdEuyu
jBCGlaIu8sXZJkn578CbjY4=
=lk0W
-----END PGP SIGNATURE-----