-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
- -- Dale
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG5KOj0hzWbkf0eKgRAl+SAJ9cf6DThblex315ip+ts93crhgsQQCeKsJH
V0UEoVFfrLXSiPdUNOqxCl0=
=1uE0
-----END PGP SIGNATURE
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
and APC does support it as well
chregu
-- Dale
--
Liip AG // Schoeneggstrasse 5 // CH-8004 Zurich
Tel +41 44 240 56 70 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x5CE1DECB
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
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 and this is a requirement but my question was, is the
provided patch compatible with the pdoru extension (the pdoru
extension works properl)?
and APC does support it as well
chregu
-- Dale
--
Liip AG // Schoeneggstrasse 5 // CH-8004 Zurich
Tel +41 44 240 56 70 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x5CE1DECB
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (Darwin)
iD8DBQFG5M240hzWbkf0eKgRAhkaAKC8KbAYFxcEXMKMkS9ABAZL7mUf/wCgj4FJ
8M2N+cAdsjkJ/tCtFuG1Ztg=
=Cqm3
-----END PGP SIGNATURE
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?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 )
{
return NULL;
}
Doesn't look like much support for m(e)mcache :)
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...
chregu
--
Liip AG // Schoeneggstrasse 5 // CH-8004 Zurich
Tel +41 44 240 56 70 // Mobile +41 76 561 88 60
www.liip.ch // blog.liip.ch // GnuPG 0x5CE1DECB
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?Ok so after examination of this extension it looks like it's
basically
using the same code with the exception of no support for memcachefrom
http://pdoru.from.ro/upload-progress-meter/upload-progress-meter-
v4.1/upload_progress_meter/upload_progress_meter.cstatic 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
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1I 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?Ok so after examination of this extension it looks like it's
basically
using the same code with the exception of no support for memcachefrom
http://pdoru.from.ro/upload-progress-meter/upload-progress-meter-
v4.1/upload_progress_meter/upload_progress_meter.cstatic 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