Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:32166 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31915 invoked by uid 1010); 10 Sep 2007 09:17:11 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 31899 invoked from network); 10 Sep 2007 09:17:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Sep 2007 09:17:11 -0000 Authentication-Results: pb1.pair.com smtp.mail=buildsmart@daleenterprise.com; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=buildsmart@daleenterprise.com; sender-id=unknown Received-SPF: error (pb1.pair.com: domain daleenterprise.com from 67.78.11.229 cause and error) X-PHP-List-Original-Sender: buildsmart@daleenterprise.com X-Host-Fingerprint: 67.78.11.229 daleenterprise.com Received: from [67.78.11.229] ([67.78.11.229:50398] helo=daleenterprise.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3A/42-19032-59B05E64 for ; Mon, 10 Sep 2007 05:17:10 -0400 Received: from localhost (localhost [127.0.0.1]) by daleenterprise.com (Postfix) with ESMTP id 6508A242CB4 for ; Mon, 10 Sep 2007 05:17:07 -0400 (EDT) Received: from daleenterprise.com ([127.0.0.1]) by localhost (daleenterprise.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16599-08 for ; Mon, 10 Sep 2007 05:17:04 -0400 (EDT) Received: from [10.1.100.11] (relay.mustangrestomods.com [67.78.11.226]) by daleenterprise.com (Postfix) with ESMTP id 8A08B242CA0 for ; Mon, 10 Sep 2007 05:16:54 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <46E4CB0B.4050700@liip.ch> <995233DC-EF1C-4EB8-979F-9FEDD82FAA1C@daleenterprise.com> <46E4CF9F.2050305@liip.ch> Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-5-655216049" Message-ID: <0E237063-A863-4B0E-805D-5D67DD3D0413@daleenterprise.com> Date: Mon, 10 Sep 2007 05:16:53 -0400 To: PHP Developers Mailing List Content-Transfer-Encoding: 7bit X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.2) MTA-Interface: amavisd-new-2.3.3 (2005-08-22) + Maia Mailguard 1.1.0 at daleenterprise.com X-Spam-Scanned: using SpamAssassin 3.1.7 (2006-10-05) at daleenterprise.com X-Virus-Scanned: using ClamAV 0.88.6 (2006-11-05) at daleenterprise.com Subject: Re: [PHP-DEV] rfc1867.c compatibility question [spoke too soon] From: buildsmart@daleenterprise.com (BuildSmart) --Apple-Mail-5-655216049 Content-Type: multipart/alternative; boundary=Apple-Mail-4-655215940 --Apple-Mail-4-655215940 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Sep 10, 2007, at 01:31:54, BuildSmart wrote: > -----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 hmm, didn't this open up a big can of worms while I wasn't paying attention!!!. I installed the turk memcache (mmcache) software a while back and while I hadn't tested the pdoru extension using it (or anything else for that matter) I thought it was working properly but it seems that it's not really compatible because a lot of issues are popping up quickly where things like phpgacl and phpbb2 become almost non- useable and simply disabling the software gets things running properly again. Perhaps I need to rethink the customers needs and go with the file convention if they want the feature otherwise it doesn't make logical sense to enable an additional feature that negatively affects everyone else. I took a quick look at Eaccelerator as a possible solution but haven't installed it because it comes with it's own set of compatibility issues, is there any other caching mechanism that is easy to implement and more compatible with the newer version of PHP or is this one of those things that should be used as implemented since no real speed benefits are achieved using such additional software that isn't already a consideration in the newer PHP distributions? -- Dale --Apple-Mail-4-655215940 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
On Sep 10, 2007, = at 01:31:54, BuildSmart wrote:

-----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

is this patch = compatible with the pdoru Upload Progress Meter extension
or do I need to write something from scratch?
=

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

static int mmcache_loaded(void) = { return 0; }
static void * callback_mmcache( = void *pointer, int read_bytes, int
total_bytes, = int what_happened )
{
=A0=A0 = 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.



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

hmm, didn't this open up a big can = of worms while I wasn't paying attention!!!.

I installed the turk = memcache (mmcache) software a while back and while I hadn't tested the = pdoru extension using it (or anything else for that matter) I thought it = was working properly but it seems that it's not really compatible = because a lot of issues are=A0popping up quickly where things like=A0phpgacl and phpbb2 become almost non-useable and simply = disabling the software gets things running properly = again.

Perhaps I need to rethink the customers needs and go with the = file convention if they want the feature otherwise it doesn't make = logical sense to enable an additional feature that negatively affects = everyone else.

I took a quick look at = Eaccelerator as a possible solution but haven't installed it because it = comes with it's own set of=A0compatibility issues, is there any other = caching mechanism that is easy to implement and more=A0compatible with = the newer version of PHP or is this one of those things that should be = used as implemented since no real speed benefits are achieved using such = additional software that isn't already a consideration in the newer PHP = distributions?

-- Dale
= --Apple-Mail-4-655215940-- --Apple-Mail-5-655216049 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG5QuF0hzWbkf0eKgRAi1xAKCDua9Le2FUrxIGFH2wmyhFjdeXrQCgvwxh z0M5iRkm5w9JUg4d0LZxNrY= =la8z -----END PGP SIGNATURE----- --Apple-Mail-5-655216049--