Bumping for new rev. See initial post for changes.
At first glance this looks GREAT, though I haven't tried it yet.
But then your initial comment of dropping support for PHP4 scares me.
I use the Drupal CMS and for many reasons it is firmly planted in PHP4 for some time to come and I would like to use phpSmug for use in Drupal, and even possibly build a Drupal module for it. However, I won't be able to do that if you drop support for PHP4.
I use the Drupal CMS and for many reasons it is firmly planted in PHP4 for some time to come...
Really? I guess it depends on what your definition of "some time to come" is. Drupal 6 was just released - it'll be the last version to support php4. If the Drupal dev cycle continues as it has been, Drupal 7 will be released in Q1 or Q2 2009, and it'll only support php >5.2.
At first glance this looks GREAT, though I haven't tried it yet.
But then your initial comment of dropping support for PHP4 scares me.
I use the Drupal CMS and for many reasons it is firmly planted in PHP4 for some time to come and I would like to use phpSmug for use in Drupal, and even possibly build a Drupal module for it. However, I won't be able to do that if you drop support for PHP4.
Please consider maintaining PHP4 support.
Hi Mike
I understand your concern, and to be honest, you're not likely to encounter many (if any) problems in the short term (I can't think of anything PHP5 specific I use at the moment, but I could be wrong).
The decision to drop PHP4 support was made to keep development quick and easy. I'm very quick at turning around fixes, and adding another PHP version to test on will only slow things down.
I also see it as counter productive when the underlying language is no longer being developed or maintained, short of possible security fixes, and accordingly, most businesses (I'm talking about ISPs here) are already running PHP5.
I think the best thing to do is test phpSmug in your env. If you do encounter anything PHP5 specific, you should be able to workout a quick PHP4 alternative in no time. Your PHP4 interpreter will error if it encounters something it doesn't know about (ie PHP5 specific).
If anyone else really really really needs PHP4 support, let me know and depending on the number of responses, I may start commenting my PHP5 specific changes in the source code so you can always revert to the PHP4 functionality if need be. This would be a sort of DIY PHP4 support - eg "if you need PHP4 support, you need to use PHP function x() instead of PHP function y()".
If anyone else really really really needs PHP4 support, let me know and depending on the number of responses, I may start commenting my PHP5 specific changes in the source code so you can always revert to the PHP4 functionality if need be.
I think even most webhosts are moving over to PHP5, so for me stick to php5. And if you find any php5 specific things list them in the docs.
Another thing. Caching with anonymous login should work (since 1.0.10 off course) for more than 6 hrs or not?
I have set the cache_expire to 1 day and after a few hrs (don't know exactly, maybe 6? ) the cached methods (in particular images.get heavy) seems to give empty results. The albums.get works ok. When I clear the cache (with the new method ) the images.get Heavy works fine again.
Now I switchted to hashed login and the caching works fine.
I will investigate further.
Erik
Comments
At first glance this looks GREAT, though I haven't tried it yet.
But then your initial comment of dropping support for PHP4 scares me.
I use the Drupal CMS and for many reasons it is firmly planted in PHP4 for some time to come and I would like to use phpSmug for use in Drupal, and even possibly build a Drupal module for it. However, I won't be able to do that if you drop support for PHP4.
Please consider maintaining PHP4 support.
Really? I guess it depends on what your definition of "some time to come" is. Drupal 6 was just released - it'll be the last version to support php4. If the Drupal dev cycle continues as it has been, Drupal 7 will be released in Q1 or Q2 2009, and it'll only support php >5.2.
Check it.
I think the overall trend of software projects migrating exclusively to php5 is a good thing. That's just my $0.02, though.
http://andersonfam.org
http://andersonfam.smugmug.com
D70 | SB-600 | Nifty Fifty | Tamron 17-50 f/2.8 | Nikon 70-300 f/4-5.6G
Hi Mike
I understand your concern, and to be honest, you're not likely to encounter many (if any) problems in the short term (I can't think of anything PHP5 specific I use at the moment, but I could be wrong).
The decision to drop PHP4 support was made to keep development quick and easy. I'm very quick at turning around fixes, and adding another PHP version to test on will only slow things down.
I also see it as counter productive when the underlying language is no longer being developed or maintained, short of possible security fixes, and accordingly, most businesses (I'm talking about ISPs here) are already running PHP5.
I think the best thing to do is test phpSmug in your env. If you do encounter anything PHP5 specific, you should be able to workout a quick PHP4 alternative in no time. Your PHP4 interpreter will error if it encounters something it doesn't know about (ie PHP5 specific).
If anyone else really really really needs PHP4 support, let me know and depending on the number of responses, I may start commenting my PHP5 specific changes in the source code so you can always revert to the PHP4 functionality if need be. This would be a sort of DIY PHP4 support - eg "if you need PHP4 support, you need to use PHP function x() instead of PHP function y()".
Cheers,
Colin
Personal Blog | Tech Blog | phpSmug
I think even most webhosts are moving over to PHP5, so for me stick to php5. And if you find any php5 specific things list them in the docs.
Another thing. Caching with anonymous login should work (since 1.0.10 off course) for more than 6 hrs or not?
I have set the cache_expire to 1 day and after a few hrs (don't know exactly, maybe 6? ) the cached methods (in particular images.get heavy) seems to give empty results. The albums.get works ok. When I clear the cache (with the new method
Now I switchted to hashed login and the caching works fine.
I will investigate further.
Erik