|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
php-general-digest-help
lists.php.net
Date: Wed Apr 16 2008 - 14:40:51 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
php-general Digest 16 Apr 2008 19:40:51 -0000 Issue 5408
Topics (messages 273031 through 273120):
How to get the HTTP authenticated user name?
273031 by: Georgios Kasapoglou
273032 by: Per Jessen
273034 by: Georgios Kasapoglou
273084 by: Daniel Brown
273086 by: Georgios Kasapoglou
Memory limit of 8 MB not enough
273033 by: Dave M G
273035 by: Per Jessen
273041 by: tedd
273044 by: Daniel Brown
273045 by: Andrew Ballard
273046 by: Daniel Brown
273047 by: Daniel Brown
273050 by: Per Jessen
273053 by: tedd
273060 by: Daniel Brown
273069 by: Per Jessen
273072 by: Andrew Ballard
273078 by: Daniel Brown
273087 by: Per Jessen
273088 by: tedd
273089 by: Daniel Brown
273091 by: David Giragosian
273098 by: Andrew Ballard
PHP Serialization Performance
273036 by: Waynn Lue
273037 by: Richard Heyes
Re: What is the practical use of "abstract" and "interface"?
273038 by: Tony Marston
273039 by: Robert Cummings
273040 by: Tony Marston
273042 by: Jay Blanchard
273090 by: Jay Blanchard
273095 by: Robin Vickery
273106 by: Robert Cummings
273111 by: Nathan Nobbe
273112 by: Robert Cummings
273113 by: Nathan Nobbe
273114 by: Nathan Nobbe
273115 by: Jeremy Privett
273116 by: Nathan Nobbe
273118 by: Jeremy Privett
Re: PHP Speech
273043 by: Thiago Pojda
273048 by: Daniel Brown
273049 by: Nathan Nobbe
273051 by: Nathan Nobbe
273052 by: Andrew Ballard
273054 by: Daniel Brown
273055 by: Nathan Nobbe
273056 by: Daniel Brown
273057 by: Nathan Nobbe
273058 by: Daniel Brown
273059 by: Andrew Ballard
273061 by: Nathan Nobbe
273062 by: Daniel Brown
273063 by: Nathan Nobbe
273064 by: Daniel Brown
273065 by: Andrew Ballard
273066 by: Nathan Nobbe
273067 by: Daniel Brown
273068 by: Nathan Nobbe
273071 by: Daniel Brown
273073 by: Nathan Nobbe
273076 by: Wolf
273077 by: Wolf
273082 by: Daniel Brown
Database abstraction?
273070 by: Jason Pruim
273074 by: David Giragosian
273075 by: Richard Heyes
273079 by: Nathan Nobbe
273080 by: Steve Holmes
273081 by: Larry Garfield
273083 by: Richard Heyes
273085 by: Nathan Nobbe
273102 by: Richard Heyes
Hack question
273092 by: Al
273093 by: Aschwin Wesselius
273094 by: Aschwin Wesselius
273096 by: Greg Bowser
273097 by: Daniel Brown
273101 by: Jim Lucas
Re: PHP with NNTP?
273099 by: vester_s
273100 by: Daniel Brown
273110 by: Per Jessen
273117 by: Daniel Brown
273119 by: Per Jessen
273120 by: Daniel Brown
Re: Forking and fsock
273103 by: Daniel Brown
Reserved var for checking remote IP address
273104 by: Javier Huerta
273105 by: Daniel Brown
273109 by: Javier Huerta
PHP Unit Test - Code Coverage - Continuous Intergration?
273107 by: Jay Paulson
273108 by: Brice
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:
Hi all,
I'm new to the list.
I'm running on Apache 2 and I want to use the mod_auth_basic module,
which authenticates the user.
But I need the username to use it in my php script. How can I?
Is there any php command or variable that keeps this info?
I searched my browser whether a cookie is created, but unfortunately
there isn't
Regards,
Georgios
attached mail follows:
Georgios Kasapoglou wrote:
> Hi all,
> I'm new to the list.
> I'm running on Apache 2 and I want to use the mod_auth_basic module,
> which authenticates the user.
> But I need the username to use it in my php script. How can I?
$_SERVER[] might have it.
/Per Jessen, Zürich
attached mail follows:
Ok,
$_SERVER["REMOTE_USER"] is the answer.
Thanks anyway.
Georgios
Georgios Kasapoglou wrote:
> Hi all,
> I'm new to the list.
> I'm running on Apache 2 and I want to use the mod_auth_basic module,
> which authenticates the user.
> But I need the username to use it in my php script. How can I?
> Is there any php command or variable that keeps this info?
> I searched my browser whether a cookie is created, but unfortunately
> there isn't
>
> Regards,
> Georgios
>
attached mail follows:
On Wed, Apr 16, 2008 at 5:37 AM, Georgios Kasapoglou <gkasapintracom.gr> wrote:
> Hi all,
> I'm new to the list.
> I'm running on Apache 2 and I want to use the mod_auth_basic module, which
> authenticates the user.
> But I need the username to use it in my php script. How can I?
> Is there any php command or variable that keeps this info?
> I searched my browser whether a cookie is created, but unfortunately there
> isn't
STFA - This comes up every couple of months or so.
http://marc.info/?w=2&r=1&s=php+auth+user&q=t
As Per indicated, it should be in $_SERVER. If memory serves
correctly, it should be something like $_SERVER['AUTH_USER'] or
$_SERVER['PHP_AUTH_USER'].
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
Thanks Daniel,
I found it in $_SERVER["REMOTE_USER"] but $_SERVER["PHP_AUTH_USER"]
(which you propose) gives me the same information.
Regards,
Georgios
Daniel Brown wrote:
> On Wed, Apr 16, 2008 at 5:37 AM, Georgios Kasapoglou <gkasapintracom.gr> wrote:
>
>> Hi all,
>> I'm new to the list.
>> I'm running on Apache 2 and I want to use the mod_auth_basic module, which
>> authenticates the user.
>> But I need the username to use it in my php script. How can I?
>> Is there any php command or variable that keeps this info?
>> I searched my browser whether a cookie is created, but unfortunately there
>> isn't
>>
>
> STFA - This comes up every couple of months or so.
> http://marc.info/?w=2&r=1&s=php+auth+user&q=t
>
> As Per indicated, it should be in $_SERVER. If memory serves
> correctly, it should be something like $_SERVER['AUTH_USER'] or
> $_SERVER['PHP_AUTH_USER'].
>
>
attached mail follows:
PHP list,
I have a PHP script that resizes an image. It takes just about whatever
size and shrinks and crops it down to 320X240.
I've found that these days, it's not uncommon for people to take images
straight off their digital camera, which can be 3000X2000 pixels in
image size, even if the jpeg file containing the image is only 200 KB.
When working with the image, it gets uncompressed and takes up a lot of
memory.
So sometimes I've seen an error in my logs that says:
Fatal error: Allowed memory size of 8388608 bytes
exhausted (tried to allocate 8000 bytes) in
/home/public_html/Action.php on line 153.
I contacted my web host provider, and they recommended increasing the
allowed allocation limit in "/etc/php.ini".
Right now my allocation limit, assuming I'm looking at the right setting
is 8 megabytes:
memory_limit = 8M ; Maximum amount of memory a script may consume (8MB)
What would be a recommended size? While I want to have enough to work
with large images, I don't want to overload the server.
Actually, I have no idea what the potential dangers are. Just on
principle I think it's a bad idea to edit php.ini without some guidance.
What should I set the memory limit to?
--
Dave M G
attached mail follows:
Dave M G wrote:
> I contacted my web host provider, and they recommended increasing the
> allowed allocation limit in "/etc/php.ini".
>
> Right now my allocation limit, assuming I'm looking at the right
> setting is 8 megabytes:
>
> memory_limit = 8M ; Maximum amount of memory a script may consume
> (8MB)
>
> What would be a recommended size? While I want to have enough to work
> with large images, I don't want to overload the server.
Unless you are constrained by memory in general, I would say 64M. But
check how much memory you have and how many pictures you expect to
process concurrently.
> Actually, I have no idea what the potential dangers are.
Using up all available memory is the only real "risk". It might lead to
swapping which in turn will most likely increase response times.
/Per Jessen, Zürich
attached mail follows:
At 6:48 PM +0900 4/16/08, Dave M G wrote:
>PHP list,
>
>I have a PHP script that resizes an image. It takes just about
>whatever size and shrinks and crops it down to 320X240.
>
>I've found that these days, it's not uncommon for people to take
>images straight off their digital camera, which can be 3000X2000
>pixels in image size, even if the jpeg file containing the image is
>only 200 KB. When working with the image, it gets uncompressed and
>takes up a lot of memory.
You might want to look into using javascript to trim the file down to
a respectable size before uploading.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
attached mail follows:
On Wed, Apr 16, 2008 at 5:48 AM, Dave M G <martinautotelic.com> wrote:
> PHP list,
>
> I have a PHP script that resizes an image. It takes just about whatever
> size and shrinks and crops it down to 320X240.
>
[snip!]
>
> So sometimes I've seen an error in my logs that says:
>
> Fatal error: Allowed memory size of 8388608 bytes
> exhausted (tried to allocate 8000 bytes) in
> /home/public_html/Action.php on line 153.
[snip!]
>
> What would be a recommended size? While I want to have enough to work with
> large images, I don't want to overload the server.
I set the server-wide setting on most of my servers to 64MB. This
includes my shared hosting servers, where resources are then monitored
otherwise and then clients who may overuse or abuse resources may be
bumped to a more powerful system (VPS, dedicated, or even just a
higher shared plan). So I'd recommend using 64MB, but monitoring
traffic as well --- because that 64MB max limit will be for each
execution of each script. So if you have 100 simultaneous connections
each using the maximum memory allowed by configuration, you're looking
at ~6.4GB memory --- clearly into swap space, and not an optimal
situation.
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
On Wed, Apr 16, 2008 at 7:56 AM, tedd <tedd.sperlinggmail.com> wrote:
> At 6:48 PM +0900 4/16/08, Dave M G wrote:
>
> > PHP list,
> >
> > I have a PHP script that resizes an image. It takes just about whatever
> size and shrinks and crops it down to 320X240.
> >
> > I've found that these days, it's not uncommon for people to take images
> straight off their digital camera, which can be 3000X2000 pixels in image
> size, even if the jpeg file containing the image is only 200 KB. When
> working with the image, it gets uncompressed and takes up a lot of memory.
> >
>
> You might want to look into using javascript to trim the file down to a
> respectable size before uploading.
>
> Cheers,
>
> tedd
I'd be interested in seeing an example of how you actually plan on
doing that, Tedd. JavaScript can't access the file from an input
field, and I'm not aware of any JavaScript image handling functions
either.
Andrew
attached mail follows:
On Wed, Apr 16, 2008 at 6:07 AM, Per Jessen <percomputer.org> wrote:
>
> > Actually, I have no idea what the potential dangers are.
>
> Using up all available memory is the only real "risk". It might lead to
> swapping which in turn will most likely increase response times.
And on a shared host, the likelihood of increased billing for
overuse of memory. If it's going to be that resource-intensive, it
may be better to consider moving to a VPS or dedicated server.
I removed my signature from this email so it doesn't look like I'm
stating this to try to sell my own stuff. ;-P
--
</Daniel P. Brown>
attached mail follows:
On Wed, Apr 16, 2008 at 7:56 AM, tedd <tedd.sperlinggmail.com> wrote:
> At 6:48 PM +0900 4/16/08, Dave M G wrote:
>
> > PHP list,
> >
> > I have a PHP script that resizes an image. It takes just about whatever
> size and shrinks and crops it down to 320X240.
> >
> > I've found that these days, it's not uncommon for people to take images
> straight off their digital camera, which can be 3000X2000 pixels in image
> size, even if the jpeg file containing the image is only 200 KB. When
> working with the image, it gets uncompressed and takes up a lot of memory.
> >
>
> You might want to look into using javascript to trim the file down to a
> respectable size before uploading.
I've never seen JavaScript's ability to work with image resizing
and such. Are you suggesting using it instead to say, "that file is
too big," before it's uploaded? If that's the case, it may not work
in Dave's situation, since he expects large files already, and
therefore has the resizing script(s) in place.
If I'm not totally off-point, I think the memory issue is more of
GD/Imagemagick being a resource hog than the actual file size, since
he pointed out that a megapixel image is sometimes still only 200K.
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
Daniel Brown wrote:
> On Wed, Apr 16, 2008 at 6:07 AM, Per Jessen <percomputer.org> wrote:
>>
>> > Actually, I have no idea what the potential dangers are.
>>
>> Using up all available memory is the only real "risk". It might
>> lead to swapping which in turn will most likely increase response
>> times.
>
> And on a shared host, the likelihood of increased billing for
> overuse of memory.
Except a shared hoster would probably not permit anyone to change
php.ini :-)
/Per Jessen, Zürich
attached mail follows:
At 9:41 AM -0400 4/16/08, Andrew Ballard wrote:
>On Wed, Apr 16, 2008 at 7:56 AM, tedd <tedd.sperlinggmail.com> wrote:
>> At 6:48 PM +0900 4/16/08, Dave M G wrote:
>>
>> > PHP list,
>> >
>> > I have a PHP script that resizes an image. It takes just about whatever
>> size and shrinks and crops it down to 320X240.
>> >
>> > I've found that these days, it's not uncommon for people to take images
>> straight off their digital camera, which can be 3000X2000 pixels in image
>> size, even if the jpeg file containing the image is only 200 KB. When
>> working with the image, it gets uncompressed and takes up a lot of memory.
>> >
>>
>> You might want to look into using javascript to trim the file down to a
>> respectable size before uploading.
>>
>> Cheers,
>>
>> tedd
>
>I'd be interested in seeing an example of how you actually plan on
>doing that, Tedd. JavaScript can't access the file from an input
>field, and I'm not aware of any JavaScript image handling functions
>either.
>
>Andrew
I saw one the other day that caught my eye -- will look into it.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
attached mail follows:
On Wed, Apr 16, 2008 at 9:57 AM, Per Jessen <percomputer.org> wrote:
> Daniel Brown wrote:
> >
> > And on a shared host, the likelihood of increased billing for
> > overuse of memory.
>
> Except a shared hoster would probably not permit anyone to change
> php.ini :-)
I do. A lot of them do.
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
Daniel Brown wrote:
> On Wed, Apr 16, 2008 at 9:57 AM, Per Jessen <percomputer.org> wrote:
>> Daniel Brown wrote:
>> >
>> > And on a shared host, the likelihood of increased billing for
>> > overuse of memory.
>>
>> Except a shared hoster would probably not permit anyone to change
>> php.ini :-)
>
> I do. A lot of them do.
I'm curious - why? To me php.ini seems to be exactly the kind of thing
you wouldn't the user to fiddle with - in a shared environment.
/Per Jessen, Zürich
attached mail follows:
On Wed, Apr 16, 2008 at 9:59 AM, tedd <tedd.sperlinggmail.com> wrote:
>
> At 9:41 AM -0400 4/16/08, Andrew Ballard wrote:
>
> > On Wed, Apr 16, 2008 at 7:56 AM, tedd <tedd.sperlinggmail.com> wrote:
> >
> > > At 6:48 PM +0900 4/16/08, Dave M G wrote:
> > >
> > > > PHP list,
> > > >
> > > > I have a PHP script that resizes an image. It takes just about
> whatever
> > > size and shrinks and crops it down to 320X240.
> > > >
> > > > I've found that these days, it's not uncommon for people to take
> images
> > > straight off their digital camera, which can be 3000X2000 pixels in
> image
> > > size, even if the jpeg file containing the image is only 200 KB. When
> > > working with the image, it gets uncompressed and takes up a lot of
> memory.
> > > >
> > >
> > > You might want to look into using javascript to trim the file down to a
> > > respectable size before uploading.
> > >
> > > Cheers,
> > >
> > > tedd
> > >
> >
> > I'd be interested in seeing an example of how you actually plan on
> > doing that, Tedd. JavaScript can't access the file from an input
> > field, and I'm not aware of any JavaScript image handling functions
> > either.
> >
> > Andrew
> >
>
>
> I saw one the other day that caught my eye -- will look into it.
>
>
>
> Cheers,
>
> tedd
The first problem I see implementing the approach is the JavaScript
sandbox. JavaScript is allowed to read the text of the input file
field (and thus know the file name and path once a file has been
selected); it cannot access the disk to actually get to the image or
do anything with it. From here, I'm thinking there are a couple things
you could do with JavaScript. The first would be to embed the image
into the web page using an IMG tag, which would allow you to determine
the pixel dimensions (but not the actual file size). The second would
be what Gmail seems to do, and actually upload the form to their
server with some sort of AJAX request, at which time your server could
return information on the size of the file. However, if the file is
too large, you're back to the original problem of needing to increase
the RAM limit in PHP.
The second problem is, as I said, I'm not aware of any JavaScript that
can manipulate the image. JavaScript can cause the display of an image
to be resized within the browser, but that doesn't actually affect the
stored file. I don't know, but I guess if you could actually get to
the bits, you could probably write an algorithm in JavaScript to
resize an image by manipulating the bits, but I think it would be
dreadfully slow if it would even run without running out of resources.
I think the only pure-client options are either Java (which would
require special permissions to get out of its own sandbox) or ActiveX.
If you know of some other approach, I'd be interested to see how it works.
Andrew
attached mail follows:
On Wed, Apr 16, 2008 at 10:36 AM, Per Jessen <percomputer.org> wrote:
>
> I'm curious - why? To me php.ini seems to be exactly the kind of thing
> you wouldn't the user to fiddle with - in a shared environment.
To allow flexibility for the user, and give them the opportunity
to customize the account to their needs. The rest of the monitors and
filters cover the server in case they do anything extremely stupid,
but other than damaging their own things by turning register_globals
on, or running their quotas to the limit allowed by the balancers
(exceeding their allotted memory usage, for example), they can't
damage the rest of the server.
It should also be mentioned that all accounts on my servers are
chroot'd (jailed), with suExec running for each. It's as if they're
the only one on the server (such as with a VPS), but without root
access, and with more limited resources.
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
Daniel Brown wrote:
> On Wed, Apr 16, 2008 at 10:36 AM, Per Jessen <percomputer.org> wrote:
>>
>> I'm curious - why? To me php.ini seems to be exactly the kind of
>> thing you wouldn't the user to fiddle with - in a shared
>> environment.
>
> To allow flexibility for the user, and give them the opportunity
> to customize the account to their needs.
I guess it's a matter of preference - I tend to think that a shared
hosting user is best restricted to whatever changes he can do
in .htaccess (with php_admin_flag etc.).
Mind you, it's not like I have hundreds of hosting customers, so maybe
my horizont is a little limited here.
/Per Jessen, Zürich
attached mail follows:
At 10:53 AM -0400 4/16/08, Andrew Ballard wrote:
>On Wed, Apr 16, 2008 at 9:59 AM, tedd <tedd.sperlinggmail.com> wrote:
>
> > I saw one the other day that caught my eye -- will look into it.
>>
>The first problem I see implementing the approach is the JavaScript
>sandbox. JavaScript is allowed to read the text of the input file
>field (and thus know the file name and path once a file has been
>selected); it cannot access the disk to actually get to the image or
>do anything with it. From here, I'm thinking there are a couple things
>you could do with JavaScript. The first would be to embed the image
>into the web page using an IMG tag, which would allow you to determine
>the pixel dimensions (but not the actual file size). The second would
>be what Gmail seems to do, and actually upload the form to their
>server with some sort of AJAX request, at which time your server could
>return information on the size of the file. However, if the file is
>too large, you're back to the original problem of needing to increase
>the RAM limit in PHP.
>
>The second problem is, as I said, I'm not aware of any JavaScript that
>can manipulate the image. JavaScript can cause the display of an image
>to be resized within the browser, but that doesn't actually affect the
>stored file. I don't know, but I guess if you could actually get to
>the bits, you could probably write an algorithm in JavaScript to
>resize an image by manipulating the bits, but I think it would be
>dreadfully slow if it would even run without running out of resources.
>
>I think the only pure-client options are either Java (which would
>require special permissions to get out of its own sandbox) or ActiveX.
>
>If you know of some other approach, I'd be interested to see how it works.
>
>Andrew
Andrew:
I think you are right -- I wasn't able to resize the image. Here's
the link that caught my eye, but it doesn't work as described:
http://javascript.internet.com/forms/image-upload-preview.html
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
attached mail follows:
On Wed, Apr 16, 2008 at 11:42 AM, Per Jessen <percomputer.org> wrote:
> Daniel Brown wrote:
>
> I guess it's a matter of preference - I tend to think that a shared
> hosting user is best restricted to whatever changes he can do
> in .htaccess (with php_admin_flag etc.).
I allow overrides in .htaccess, too. Not sure what your thinking
is on that.
> Mind you, it's not like I have hundreds of hosting customers, so maybe
> my horizont is a little limited here.
I don't have hundreds right now either. I had a company several
years ago, which I've since sold, that had about three hundred
accounts, but any more, I like to keep lower numbers per server.
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
On 4/16/08, tedd <tedd.sperlinggmail.com> wrote:
>
> At 10:53 AM -0400 4/16/08, Andrew Ballard wrote:
>
> > On Wed, Apr 16, 2008 at 9:59 AM, tedd <tedd.sperlinggmail.com> wrote:
> >
> > > I saw one the other day that caught my eye -- will look into it.
> >
> > >
> > > The first problem I see implementing the approach is the JavaScript
> > sandbox. JavaScript is allowed to read the text of the input file
> > field (and thus know the file name and path once a file has been
> > selected); it cannot access the disk to actually get to the image or
> > do anything with it. From here, I'm thinking there are a couple things
> > you could do with JavaScript. The first would be to embed the image
> > into the web page using an IMG tag, which would allow you to determine
> > the pixel dimensions (but not the actual file size). The second would
> > be what Gmail seems to do, and actually upload the form to their
> > server with some sort of AJAX request, at which time your server could
> > return information on the size of the file. However, if the file is
> > too large, you're back to the original problem of needing to increase
> > the RAM limit in PHP.
> >
> > The second problem is, as I said, I'm not aware of any JavaScript that
> > can manipulate the image. JavaScript can cause the display of an image
> > to be resized within the browser, but that doesn't actually affect the
> > stored file. I don't know, but I guess if you could actually get to
> > the bits, you could probably write an algorithm in JavaScript to
> > resize an image by manipulating the bits, but I think it would be
> > dreadfully slow if it would even run without running out of resources.
> >
> > I think the only pure-client options are either Java (which would
> > require special permissions to get out of its own sandbox) or ActiveX.
> >
> > If you know of some other approach, I'd be interested to see how it
> > works.
> >
> > Andrew
> >
>
>
> Andrew:
>
> I think you are right -- I wasn't able to resize the image. Here's the
> link that caught my eye, but it doesn't work as described:
>
> http://javascript.internet.com/forms/image-upload-preview.html
>
> Cheers,
>
> tedd
> --
>
It worked for me using IE on XP.
David
attached mail follows:
On Wed, Apr 16, 2008 at 12:00 PM, David Giragosian
<dgiragosiangmail.com> wrote:
>
> On 4/16/08, tedd <tedd.sperlinggmail.com> wrote:
> >
> > At 10:53 AM -0400 4/16/08, Andrew Ballard wrote:
> >
> > > On Wed, Apr 16, 2008 at 9:59 AM, tedd <tedd.sperlinggmail.com> wrote:
> > >
> > > > I saw one the other day that caught my eye -- will look into it.
> > >
> > > >
> > > > The first problem I see implementing the approach is the JavaScript
> > > sandbox. JavaScript is allowed to read the text of the input file
> > > field (and thus know the file name and path once a file has been
> > > selected); it cannot access the disk to actually get to the image or
> > > do anything with it. From here, I'm thinking there are a couple things
> > > you could do with JavaScript. The first would be to embed the image
> > > into the web page using an IMG tag, which would allow you to determine
> > > the pixel dimensions (but not the actual file size). The second would
> > > be what Gmail seems to do, and actually upload the form to their
> > > server with some sort of AJAX request, at which time your server could
> > > return information on the size of the file. However, if the file is
> > > too large, you're back to the original problem of needing to increase
> > > the RAM limit in PHP.
> > >
> > > The second problem is, as I said, I'm not aware of any JavaScript that
> > > can manipulate the image. JavaScript can cause the display of an image
> > > to be resized within the browser, but that doesn't actually affect the
> > > stored file. I don't know, but I guess if you could actually get to
> > > the bits, you could probably write an algorithm in JavaScript to
> > > resize an image by manipulating the bits, but I think it would be
> > > dreadfully slow if it would even run without running out of resources.
> > >
> > > I think the only pure-client options are either Java (which would
> > > require special permissions to get out of its own sandbox) or ActiveX.
> > >
> > > If you know of some other approach, I'd be interested to see how it
> > > works.
> > >
> > > Andrew
> > >
> >
> >
> > Andrew:
> >
> > I think you are right -- I wasn't able to resize the image. Here's the
> > link that caught my eye, but it doesn't work as described:
> >
> > http://javascript.internet.com/forms/image-upload-preview.html
> >
> > Cheers,
> >
> > tedd
> > --
> >
>
>
> It worked for me using IE on XP.
>
> David
>
I get nothing in either browser.
FF: only the first header line; no content
HTTP/0.9 200 OK
IE:
The page cannot be displayed
The page you are looking for is currently unavailable. The Web site
might be experiencing technical difficulties, or you may need to
adjust your browser settings.
[snip]
Cannot find server or DNS Error
Andrew
HTTP/0.9 200 OK
Andrew
attached mail follows:
I'm using PHP to cache files that are backed by the database. In the
course of writing these functions, I end up with a set of variables
that are needed by my application, returned in an array. I can either
directly generate the array in a .php file, then use require_once to
get that variable, or I can use PHP serialization, write that array
out to a file, then in my application read the array in, deserialize,
etc.
I spent awhile trying to look at the performance of php serialization,
but except for one unsubstantiated comment on the php serialize() doc
page, I haven't found much. Does anyone have any knowledge of that,
and also of the two approaches in general? The pro of the
serialization is that I think it's slightly easier to write, but the
con is that it's harder to read.
Thanks!
attached mail follows:
> I'm using PHP to cache files that are backed by the database. In the
> course of writing these functions, I end up with a set of variables
> that are needed by my application, returned in an array. I can either
> directly generate the array in a .php file, then use require_once to
> get that variable, or I can use PHP serialization, write that array
> out to a file, then in my application read the array in, deserialize,
> etc.
>
> I spent awhile trying to look at the performance of php serialization,
> but except for one unsubstantiated comment on the php serialize() doc
> page, I haven't found much. Does anyone have any knowledge of that,
> and also of the two approaches in general? The pro of the
> serialization is that I think it's slightly easier to write, but the
> con is that it's harder to read.
Not taking into account the actual performance (you must decide how
important this is to you), the quickest to implement would be a
combination of serialize(), unserialize(), file_put_contents() and
file_get_contents().
Using these functions you could very quickly create a persistent cache
for data. It might be quicker though to use a cache that's already out
there.
--
Richard Heyes
Employ me:
http://www.phpguru.org/cv
attached mail follows:
The term "abstract" has been adequately defined in this thread, so I won't
repeat it.
However, there is one important aspect of the term "interface" which I think
that most people seem to miss - it is not necessary to use the term
"interface" in order to have an interface. Let me explain with a code
sample:
class foo {
function something ($arg1, $arg2, ...) {
....
} // end something
} // end class foo
Here I have defined a class "foo" with a method called "something". This
method as it stands is already an interface (as in Application Program
Interface or API) and does not require anything extra for it to be accessed.
All I need is the following:
$foo = new foo.
$result = $foo->something($arg1, $arg2, ...);
In order to include the term "interface" in the code you need something like
the following (which is taken from the PHP manual):
// Declare the interface 'iTemplate'
interface iTemplate
{
public function setVariable($name, $var);
public function getHtml($template);
}
// Implement the interface
// This will work
class Template implements iTemplate
{
private $vars = array();
public function setVariable($name, $var)
{
$this->vars[$name] = $var;
}
public function getHtml($template)
{
foreach($this->vars as $name => $value) {
$template = str_replace('{' . $name . '}', $value, $template);
}
return $template;
}
}
All that extra code for absolutely no benefit! It is possible to define an
interface (as in API) without actually using the term "interface", so IMHO
the term "interface" is totally redundant and a waste of time.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
""Daevid Vincent"" <daeviddaevid.com> wrote in message
news:0ba401c89f88$a7395460$450a0a0alocutus...
> -----Original Message-----
> From: Larry Garfield [mailto:larrygarfieldtech.com]
>
> If your code doesn't have an API and clear separation of
> parts, then neither
> abstract classes nor interfaces are useful to you.
>
> If you're coding anything of respectable size, vis, more than
> a one-off 1000
> line script or less, then you either want to have an API and
> clear separation
> of parts or I don't want to hire you, because your code is
> going to be an unmaintainable mess.
That is soooo not true. My last company had nearly 15 developers and we
never used either of these concepts in the six years the company existed. We
had perhaps 50+ classes and some had upwards of 5-KLOC each. We had three
databases with almost 300 tables. We had an external XML API that hooked
into these classes with 'set', 'get', 'add', 'delete' and all the commands
you would expect. And we weren't doing simple stuff either. This was an
extremely complex appliance that was HEAVILY PHP/Ruby driven
(http://www.lockdownnetworks.com).
I'm not trying to start a war here, I just really don't see how any PHP
project other than the very fringe examples such as a DB abstraction project
or huge PEAR project has any _real_ need for this. Sure, it's all text-book
and "proper" perhaps, but to me it just seems like bloat and if you intend
to extend a given class, you STILL have to read the source code and examine
the abstract class or interface anyways to know what you have to implement
in your derived class (right?)
90% of the LAMP projects amount to some website/service, some user
registration, some blogs or threaded discussion, some database entries.
They're really not all that complex in the big picture.
I can sort of see the use for these if you were designing an operating
system or a device driver or something HUGE. But come on -- a website is
really not that big (code wise). It may have thousands of pages, but they're
built from a relatively small amount of dynamic PHP pages.
In any event, thanks for your detailed reply Larry. I get the concepts. I
just don't see the general-use-case need in PHP's OOP world. Maybe sometime
the light-switch will flip on for me and I'll realize I've been skating
uphill all these years...
Daevid.
P.S. you should look at my resume before you decide not to hire me ;-p
http://resume.daevid.com
attached mail follows:
On Wed, 2008-04-16 at 12:20 +0100, Tony Marston wrote:
> The term "abstract" has been adequately defined in this thread, so I won't
> repeat it.
>
> However, there is one important aspect of the term "interface" which I think
> that most people seem to miss - it is not necessary to use the term
> "interface" in order to have an interface. Let me explain with a code
> sample:
>
> class foo {
> function something ($arg1, $arg2, ...) {
> ....
> } // end something
> } // end class foo
>
> Here I have defined a class "foo" with a method called "something". This
> method as it stands is already an interface (as in Application Program
> Interface or API) and does not require anything extra for it to be accessed.
> All I need is the following:
>
> $foo = new foo.
> $result = $foo->something($arg1, $arg2, ...);
>
> In order to include the term "interface" in the code you need something like
> the following (which is taken from the PHP manual):
>
> // Declare the interface 'iTemplate'
> interface iTemplate
> {
> public function setVariable($name, $var);
> public function getHtml($template);
> }
>
> // Implement the interface
> // This will work
> class Template implements iTemplate
> {
> private $vars = array();
>
> public function setVariable($name, $var)
> {
> $this->vars[$name] = $var;
> }
>
> public function getHtml($template)
> {
> foreach($this->vars as $name => $value) {
> $template = str_replace('{' . $name . '}', $value, $template);
> }
>
> return $template;
> }
> }
>
> All that extra code for absolutely no benefit! It is possible to define an
> interface (as in API) without actually using the term "interface", so IMHO
> the term "interface" is totally redundant and a waste of time.
While I agree that Interfaces are mostly a lot of extra code, I have to
also say that they are there primarily to enforce a contract between the
user of the interface and their classes that claim to implement the
interface. If someone creates a class that "Implements" an interface,
then when I have to go edit or use the class, it had better damn well
implement what it says it does :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
attached mail follows:
"Robert Cummings" <robertinterjinn.com> wrote in message
news:1208345298.2036.19.camelblobule...
>
> On Wed, 2008-04-16 at 12:20 +0100, Tony Marston wrote:
>> The term "abstract" has been adequately defined in this thread, so I
>> won't
>> repeat it.
>>
>> However, there is one important aspect of the term "interface" which I
>> think
>> that most people seem to miss - it is not necessary to use the term
>> "interface" in order to have an interface. Let me explain with a code
>> sample:
>>
>> class foo {
>> function something ($arg1, $arg2, ...) {
>> ....
>> } // end something
>> } // end class foo
>>
>> Here I have defined a class "foo" with a method called "something". This
>> method as it stands is already an interface (as in Application Program
>> Interface or API) and does not require anything extra for it to be
>> accessed.
>> All I need is the following:
>>
>> $foo = new foo.
>> $result = $foo->something($arg1, $arg2, ...);
>>
>> In order to include the term "interface" in the code you need something
>> like
>> the following (which is taken from the PHP manual):
>>
>> // Declare the interface 'iTemplate'
>> interface iTemplate
>> {
>> public function setVariable($name, $var);
>> public function getHtml($template);
>> }
>>
>> // Implement the interface
>> // This will work
>> class Template implements iTemplate
>> {
>> private $vars = array();
>>
>> public function setVariable($name, $var)
>> {
>> $this->vars[$name] = $var;
>> }
>>
>> public function getHtml($template)
>> {
>> foreach($this->vars as $name => $value) {
>> $template = str_replace('{' . $name . '}', $value,
>> $template);
>> }
>>
>> return $template;
>> }
>> }
>>
>> All that extra code for absolutely no benefit! It is possible to define
>> an
>> interface (as in API) without actually using the term "interface", so
>> IMHO
>> the term "interface" is totally redundant and a waste of time.
>
> While I agree that Interfaces are mostly a lot of extra code, I have to
> also say that they are there primarily to enforce a contract between the
> user of the interface and their classes that claim to implement the
> interface. If someone creates a class that "Implements" an interface,
> then when I have to go edit or use the class, it had better damn well
> implement what it says it does :)
"enforcing a contract" is a lot of maningless gobbledegook. The simple fact
is that it is possible to have an interface without ever using the term
"interface". Nothing extra is added by using the term "interface" (except
for effort) so there is absolutely no advantage in doing so. That is why I
say that the term "interface" is a waste of effort as absolutely nothng is
gained.
--
Tony Marston
http://www.tonymarston.net
http://www.radicore.org
> Cheers,
> Rob.
> --
> http://www.interjinn.com
> Application and Templating Framework for PHP
>
attached mail follows:
[snip]
"enforcing a contract" is a lot of maningless gobbledegook. The simple
fact
is that it is possible to have an interface without ever using the term
"interface". Nothing extra is added by using the term "interface"
(except
for effort) so there is absolutely no advantage in doing so. That is why
I
say that the term "interface" is a waste of effort as absolutely nothng
is
gained.
[/snip]
What about encapsulation? Also, there is an advantage to interfaces that
has not been mentioned yet, the fact that a class can implement multiple
interfaces (polymorphism). And yes, I know that I can extend by
inheritance to create polymorphism too, but what is the most efficient
method? It depends on the application.
Like anything else interfaces are a tool and there may be multiple tools
that can accomplish the same job (i.e. table saw, band saw, hand saw).
Pick the one that is right for you.
attached mail follows:
[snip]
> What about encapsulation?
Interfaces have nothing to do with encapsulation for the smple reason
that I
can have encapsulation without using interfaces.
> Also, there is an advantage to
> interfaces that has not been mentioned yet, the fact that a
> class can implement multiple interfaces (polymorphism).
Interfaces have nothing to do with polymorphism for the smple reason
that I
can have polymorphism without using interfaces.
> And
> yes, I know that I can extend by inheritance to create
> polymorphism too, but what is the most efficient method? It
> depends on the application.
>
> Like anything else interfaces are a tool and there may be
> multiple tools that can accomplish the same job (i.e. table
> saw, band saw, hand saw). Pick the one that is right for you.
You are still missing the fundamental point. There is absolutely nothing
I
can do WITH interfaces that I cannot do WITHOUT them, therefore they are
redundant.
[/snip]
I never said that they were not redundant, I acknowledged that they
were. I you can do without them or choose to do without them then that
totally up to you.
attached mail follows:
On 16/04/2008, Jay Blanchard <jblanchardpocket.com> wrote:
> [snip]
> > What about encapsulation?
>
> Interfaces have nothing to do with encapsulation for the smple reason
> that I
> can have encapsulation without using interfaces.
Unique use of logic there.
By similar reasoning; swimming trunks have nothing to do with swimming
for the simple reason that I can swim without trunks.
> You are still missing the fundamental point. There is absolutely
> nothing I can do WITH interfaces that I cannot do WITHOUT them,
> therefore they are redundant.
How about compile-time checking that the interface has been correctly
implemented?
-robin
attached mail follows:
On Wed, 2008-04-16 at 17:22 +0100, Robin Vickery wrote:
> On 16/04/2008, Jay Blanchard <jblanchardpocket.com> wrote:
> > [snip]
> > > What about encapsulation?
> >
> > Interfaces have nothing to do with encapsulation for the smple reason
> > that I
> > can have encapsulation without using interfaces.
>
> Unique use of logic there.
>
> By similar reasoning; swimming trunks have nothing to do with swimming
> for the simple reason that I can swim without trunks.
>
> > You are still missing the fundamental point. There is absolutely
> > nothing I can do WITH interfaces that I cannot do WITHOUT them,
> > therefore they are redundant.
>
> How about compile-time checking that the interface has been correctly
> implemented?
Exactly, I was about to write the same line to Tony. Yes, you can do
everything without interfaces (and I do), but some people like the
safety net of compile time checks for full implementation of the
interfaces requirements... the problem is when you're testing the
buildup of code for an interface, you often make function stubs until
you get to them... and you might forget one ;)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
attached mail follows:
On Wed, Apr 16, 2008 at 5:47 AM, Tony Marston <tonymarston-home.demon.co.uk>
wrote:
>
> "Robert Cummings" <robertinterjinn.com> wrote in message
> > While I agree that Interfaces are mostly a lot of extra code, I have to
> > also say that they are there primarily to enforce a contract between the
> > user of the interface and their classes that claim to implement the
> > interface. If someone creates a class that "Implements" an interface,
> > then when I have to go edit or use the class, it had better damn well
> > implement what it says it does :)
>
> "enforcing a contract" is a lot of maningless gobbledegook. The simple
> fact
> is that it is possible to have an interface without ever using the term
> "interface". Nothing extra is added by using the term "interface" (except
> for effort) so there is absolutely no advantage in doing so. That is why I
> say that the term "interface" is a waste of effort as absolutely nothng is
> gained.
can u say dejavu ??
lets c if we can get another 100 post thread going like we did last year :D
this is turning into a dup.
-nathan
attached mail follows:
On Wed, 2008-04-16 at 12:43 -0600, Nathan Nobbe wrote:
> On Wed, Apr 16, 2008 at 5:47 AM, Tony Marston <tonymarston-home.demon.co.uk>
> wrote:
>
> >
> > "Robert Cummings" <robertinterjinn.com> wrote in message
> > > While I agree that Interfaces are mostly a lot of extra code, I have to
> > > also say that they are there primarily to enforce a contract between the
> > > user of the interface and their classes that claim to implement the
> > > interface. If someone creates a class that "Implements" an interface,
> > > then when I have to go edit or use the class, it had better damn well
> > > implement what it says it does :)
> >
> > "enforcing a contract" is a lot of maningless gobbledegook. The simple
> > fact
> > is that it is possible to have an interface without ever using the term
> > "interface". Nothing extra is added by using the term "interface" (except
> > for effort) so there is absolutely no advantage in doing so. That is why I
> > say that the term "interface" is a waste of effort as absolutely nothng is
> > gained.
>
>
> can u say dejavu ??
>
> lets c if we can get another 100 post thread going like we did last year :D
> this is turning into a dup.
I've been on this list long enough to know that 99% of what comes across
is a dupe :)
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
attached mail follows:
On Wed, Apr 16, 2008 at 12:01 PM, Robert Cummings <robertinterjinn.com>
wrote:
>
> On Wed, 2008-04-16 at 17:22 +0100, Robin Vickery wrote:
> > On 16/04/2008, Jay Blanchard <jblanchardpocket.com> wrote:
> > > [snip]
> > > > What about encapsulation?
> > >
> > > Interfaces have nothing to do with encapsulation for the smple reason
> > > that I
> > > can have encapsulation without using interfaces.
> >
> > Unique use of logic there.
> >
> > By similar reasoning; swimming trunks have nothing to do with swimming
> > for the simple reason that I can swim without trunks.
> >
> > > You are still missing the fundamental point. There is absolutely
> > > nothing I can do WITH interfaces that I cannot do WITHOUT them,
> > > therefore they are redundant.
> >
> > How about compile-time checking that the interface has been correctly
> > implemented?
>
> Exactly, I was about to write the same line to Tony. Yes, you can do
> everything without interfaces (and I do), but some people like the
> safety net of compile time checks for full implementation of the
> interfaces requirements... the problem is when you're testing the
> buildup of code for an interface, you often make function stubs until
> you get to them... and you might forget one ;)
yes; i like them a lot. they make concepts explicit and code easier to
understand. its very clear that when implementing an interface, in the
technical terms of the language (php), that you have to fill in all the
blanks. on the contrary, w/o the keyword hopefully youll be able to test in
development and catch those missing blanks before the code ships off to
production :)
but heres the way i look at it, if youre in a class thats been hanging
around for a while, you see a bunch of methods in there that are
'implicitly' implementing an interface, it could take you some time to
determine why theyre even there in the first place. in which case, youll
have to rely on good documentation of the code. interfaces take this to a
higher level, and make it very clear why a certain set of functions are in
the code.
if you ask me; interfaces are awesome; theyre lightweight versions of
abstract classes or in c++ terms they are purely virtual classes. you dont
run the risk of getting a bunch of potentially harmful behavior from a
abstract base class; and you dont bloat up a class hierarchy either. in
fact, thats where the interface keyword came from, if im not mistaken. back
in the day, the c++ guys were writing virtual classes where every method was
virtual. java took it one step further; they determined, well theres this
trend here; why dont we bring it to the fore and give it a particular term.
php has simply followed suit w/ this most excellent paradigm.
btw. everything i said in the conversation 6 months back is still valid and
i stand behind every bit of it.
to OP; grab a design patterns book, like heads first, gang of four, or
martin fowler - patterns of enterprise application architecture for great
practical examples of interface keyword application. you might also look
through the archives about an example i posted for the multiple inheritance
workaround using interfaces and composition. this is the java way, and now
ultimately the php way as well :D
-nathan
attached mail follows:
On Wed, Apr 16, 2008 at 12:54 PM, Robert Cummings <robertinterjinn.com>
wrote:
>
> On Wed, 2008-04-16 at 12:43 -0600, Nathan Nobbe wrote:
> > On Wed, Apr 16, 2008 at 5:47 AM, Tony Marston <
> tonymarston-home.demon.co.uk>
> > wrote:
> >
> > >
> > > "Robert Cummings" <robertinterjinn.com> wrote in message
> > > > While I agree that Interfaces are mostly a lot of extra code, I have
> to
> > > > also say that they are there primarily to enforce a contract between
> the
> > > > user of the interface and their classes that claim to implement the
> > > > interface. If someone creates a class that "Implements" an
> interface,
> > > > then when I have to go edit or use the class, it had better damn
> well
> > > > implement what it says it does :)
> > >
> > > "enforcing a contract" is a lot of maningless gobbledegook. The simple
> > > fact
> > > is that it is possible to have an interface without ever using the
> term
> > > "interface". Nothing extra is added by using the term "interface"
> (except
> > > for effort) so there is absolutely no advantage in doing so. That is
> why I
> > > say that the term "interface" is a waste of effort as absolutely
> nothng is
> > > gained.
> >
> >
> > can u say dejavu ??
> >
> > lets c if we can get another 100 post thread going like we did last year
> :D
> > this is turning into a dup.
>
> I've been on this list long enough to know that 99% of what comes across
> is a dupe :)
>
awesome; lets see if we can break 100 this time around ;)
-nathan
attached mail follows:
Nathan Nobbe wrote:
> On Wed, Apr 16, 2008 at 5:47 AM, Tony Marston <tonymarston-home.demon.co.uk>
> wrote:
>
>
>> "Robert Cummings" <robertinterjinn.com> wrote in message
>>
>>> While I agree that Interfaces are mostly a lot of extra code, I have to
>>> also say that they are there primarily to enforce a contract between the
>>> user of the interface and their classes that claim to implement the
>>> interface. If someone creates a class that "Implements" an interface,
>>> then when I have to go edit or use the class, it had better damn well
>>> implement what it says it does :)
>>>
>> "enforcing a contract" is a lot of maningless gobbledegook. The simple
>> fact
>> is that it is possible to have an interface without ever using the term
>> "interface". Nothing extra is added by using the term "interface" (except
>> for effort) so there is absolutely no advantage in doing so. That is why I
>> say that the term "interface" is a waste of effort as absolutely nothng is
>> gained.
>>
>
>
> can u say dejavu ??
>
> lets c if we can get another 100 post thread going like we did last year :D
> this is turning into a dup.
>
> -nathan
>
>
This is a holy war that is never going to end. It boils down to personal
and professional preferences. The fact of the matter is, if a company
uses these concepts and you don't know, understand, or execute that
knowledge in an interview, chances are you're not going to be hired. It
doesn't matter what your personal opinion is on the feature of the language.
Useless or not, if it's not your project, you don't get to make that
call. If it is your project, do whatever you want.
--
Jeremy Privett
C.E.O. & C.S.A.
Omega Vortex Corporation
http://www.omegavortex.net
Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
attached mail follows:
On Wed, Apr 16, 2008 at 12:56 PM, Jeremy Privett <jeremyomegavortex.net>
wrote:
> This is a holy war that is never going to end. It boils down to personal
> and professional preferences. The fact of the matter is, if a company uses
> these concepts and you don't know, understand, or execute that knowledge in
> an interview, chances are you're not going to be hired. It doesn't matter
> what your personal opinion is on the feature of the language.
>
> Useless or not, if it's not your project, you don't get to make that call.
> If it is your project, do whatever you want.
>
quite concise. i would venture to say that php is broad enough in its
feature set that there are jobs out there for developers all over the
spectrum on paradigm preference. that said, id also venture to say that
many of the larger php shops out there are looking for the oop concepts; and
yes, im including interfaces in there; tho many companies that are oop dont
care about them. on top of that; i think facebook is like only somewhat
oop. they showed us some of their code when i was in dc. and a lot of it
was procedural.
-nathan
attached mail follows:
Nathan Nobbe wrote:
> On Wed, Apr 16, 2008 at 12:56 PM, Jeremy Privett <jeremyomegavortex.net>
> wrote:
>
>
>> This is a holy war that is never going to end. It boils down to personal
>> and professional preferences. The fact of the matter is, if a company uses
>> these concepts and you don't know, understand, or execute that knowledge in
>> an interview, chances are you're not going to be hired. It doesn't matter
>> what your personal opinion is on the feature of the language.
>>
>> Useless or not, if it's not your project, you don't get to make that call.
>> If it is your project, do whatever you want.
>>
>>
>
> quite concise. i would venture to say that php is broad enough in its
> feature set that there are jobs out there for developers all over the
> spectrum on paradigm preference. that said, id also venture to say that
> many of the larger php shops out there are looking for the oop concepts; and
> yes, im including interfaces in there; tho many companies that are oop dont
> care about them. on top of that; i think facebook is like only somewhat
> oop. they showed us some of their code when i was in dc. and a lot of it
> was procedural.
>
> -nathan
>
>
Absolutely. There's enough out there to get whatever you're looking for,
if you do the work and look hard enough. A place I worked at last year
had its infrastructure centered around this system called XOBase (
http://www.xobase.com ) which is arguably the worst system I've worked
with in my life. It was all procedural, though. Not a shread of OOP to
find there until after I started. I quit shortly after I started because
the place completely misrepresented the work I was supposed to be doing,
the working environment, and a lot more that I can't say here. There
were four developers working on one system, one remotely on the opposite
side of the country, and the company didn't even use anything resembling
source control. I can't tell you the number of problems they had when
trying to roll out releases. I started in the middle of a release cycle,
so they wouldn't take the time to let me try and implement at least SVN
for their source control woes.
Moral of the story, there's plenty of stuff out there, and a lot of it
really isn't that great. Good luck with whatever you choose to do.
--
Jeremy Privett
C.E.O. & C.S.A.
Omega Vortex Corporation
http://www.omegavortex.net
Please note: This message has been sent with information that could be confidential and meant only for the intended recipient. If you are not the intended recipient, please delete all copies and inform us of the error as soon as possible. Thank you for your cooperation.
attached mail follows:
{Top Posting}
I don't know if I'm just lazy or stupid (or both).
I went into a similar issue few weeks ago and my solution was to add a
function to delete files created in the last X hours (mine was 24), and call
it on the same script that creates the files.
Which means it tries to clean up old files every time it creates a new one.
Is that any good for you guys?
Regards,
Thiago
-----Mensagem original-----
De: Daniel Brown [mailto:parasanegmail.com]
Enviada em: terça-feira, 15 de abril de 2008 21:05
Para: tedd
Cc: php-generallists.php.net
Assunto: Re: [PHP] PHP Speech
On Tue, Apr 15, 2008 at 7:04 PM, tedd <tedd.sperlinggmail.com> wrote:
>
> Your hosting service provides the capability to turn html text to
> speech, as I've done here:
[snip!]
>
> But, how do we delete the file? The php script is history after
> presenting the page and javascript can't touch the server, right? So,
> how does one delete the wave file?
>
> The only way I can see is to set up a cron job to delete all wave
> files after a certain time, but that's kind-of lame. Is there
another way?
Right, but unfortunately, because it's audio that needs to
stream, it can't just be served like an image (think GD or
imagemagick) and then destroyed. There is no way to know how
long it will be before the client receives the entire file, and
it would prove to be too much to store in a reasonable buffer.
That's why I had to write it the way it is. The drawback
is that, yes, unless you're overwriting the file each time
(which, with high-traffic sites, would corrupt larger files
mid-download), you either have to have a script to unlink() the
files or a cron to remove them (or resort to a manual removal).
I'm all ears, eyes, and cerebellum if you've got an idea on
how to fix that though. The next phase should have better
speech, I'm just having a tough time with paid gigs now and
find no time to focus on the fun stuff really. I still don't
know why no one ever told us the truth that, no matter how much
we wanted to be Toys 'R' Us kids, the answer was unscrupulously
the same: tough nuts.
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting
$19.99/mo., and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
--
PHP General Mailing List (http://www.php.net/) To unsubscribe,
visit: http://www.php.net/unsub.php
attached mail follows:
On Wed, Apr 16, 2008 at 9:37 AM, Thiago Pojda
<thiago.pojdasoftpartech.com.br> wrote:
>
> I don't know if I'm just lazy or stupid (or both).
Stupid, definitely not. Lazy.... well, maybe. ;-P
> I went into a similar issue few weeks ago and my solution was to add a
> function to delete files created in the last X hours (mine was 24), and call
> it on the same script that creates the files.
>
> Which means it tries to clean up old files every time it creates a new one.
>
> Is that any good for you guys?
It's a great idea in theory, but my concern is the duration in
which the files are unlink()'d from the system; the function is called
when another file is created - presumably when another user accesses
the page - which then lengthens the time before each user after the
first will be able to see the end result.
Now there is a very long, but very valid, run-on sentence. ;-D
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
On Wed, Apr 16, 2008 at 7:37 AM, Thiago Pojda <
thiago.pojdasoftpartech.com.br> wrote:
> {Top Posting}
>
> I don't know if I'm just lazy or stupid (or both).
>
> I went into a similar issue few weeks ago and my solution was to add a
> function to delete files created in the last X hours (mine was 24), and
> call
> it on the same script that creates the files.
>
> Which means it tries to clean up old files every time it creates a new
> one.
>
> Is that any good for you guys?
it sounds like thats what theyre talking about doing...
i was thinking, maybe put something in the session. a variable to indicate
the file was generated for some page. so like, on the page that the clip is
produced for, you drop a value in the session. maybe a path to the file;
and that would go in some array index like
$_SESSION['lastSoundByte']
so then, at the beginning part of the logic for building a page you include
something along the lines of
if(!empty($_SESSION['lastSoundByte'])) { unlink($_SESSION['lastSoundByte']);
}
that way, you could get rid of them almost as quickly as they are created;
you wont be overwriting any files for different users, and you have the
garuantee that the sound bytes will no longer be required for use by the
clients. because theyve gone to another page ;) and you eliminate any
issue about knowing when the file has been completely downloaded by the
client.
i would still consider a cron as a cleanup script tho...
-nathan
attached mail follows:
On Wed, Apr 16, 2008 at 7:53 AM, Daniel Brown <parasanegmail.com> wrote:
> On Wed, Apr 16, 2008 at 9:37 AM, Thiago Pojda
> <thiago.pojdasoftpartech.com.br> wrote:
> >
> > I don't know if I'm just lazy or stupid (or both).
>
> Stupid, definitely not. Lazy.... well, maybe. ;-P
>
> > I went into a similar issue few weeks ago and my solution was to add a
> > function to delete files created in the last X hours (mine was 24), and
> call
> > it on the same script that creates the files.
> >
> > Which means it tries to clean up old files every time it creates a new
> one.
> >
> > Is that any good for you guys?
>
> It's a great idea in theory, but my concern is the duration in
> which the files are unlink()'d from the system; the function is called
> when another file is created - presumably when another user accesses
> the page - which then lengthens the time before each user after the
> first will be able to see the end result.
well since i dont have your service dan, im filling in blanks over here;
but, do users get to determine the name of the files that get created by
this script, or at least rename them; that could be very beneficial.
run on sentence #2 ;D
-nathan
attached mail follows:
On Wed, Apr 16, 2008 at 9:53 AM, Daniel Brown <parasanegmail.com> wrote:
> On Wed, Apr 16, 2008 at 9:37 AM, Thiago Pojda
> <thiago.pojdasoftpartech.com.br> wrote:
> >
> > I don't know if I'm just lazy or stupid (or both).
>
> Stupid, definitely not. Lazy.... well, maybe. ;-P
>
>
> > I went into a similar issue few weeks ago and my solution was to add a
> > function to delete files created in the last X hours (mine was 24), and call
> > it on the same script that creates the files.
> >
> > Which means it tries to clean up old files every time it creates a new one.
> >
> > Is that any good for you guys?
>
> It's a great idea in theory, but my concern is the duration in
> which the files are unlink()'d from the system; the function is called
> when another file is created - presumably when another user accesses
> the page - which then lengthens the time before each user after the
> first will be able to see the end result.
>
In addition to the added time, aren't there any problems with race
conditions if two users try to create a file at the same time and each
user's script tries to clean the same files at the same time?
Andrew
attached mail follows:
On Wed, Apr 16, 2008 at 9:56 AM, Nathan Nobbe <quickshiftingmail.com> wrote:
>
> it sounds like thats what theyre talking about doing...
>
[snip!]
>
> that way, you could get rid of them almost as quickly as they are created;
> you wont be overwriting any files for different users, and you have the
> garuantee that the sound bytes will no longer be required for use by the
> clients. because theyve gone to another page ;) and you eliminate any
> issue about knowing when the file has been completely downloaded by the
> client.
A great idea if the audio is only being used as an embedded object
within a page. However, if a developer wants to use the functions to
create audio clips for another reason, the session expiration won't
work.
Conversely, if a developer wants to use the functions to create
audio clips for another reason, he or she will probably already have a
way of cleaning that up, as well! ;-P
I suppose that further validates the idea.
> i would still consider a cron as a cleanup script tho...
I still think it's the best and most responsible way. However,
I'm also kicking around the idea of giving each member a larger
private tmp directory, that can then be cleaned out using Thiago's
idea - anything older than n hours is deleted by a function run from a
root cron.
And no, to those of you who are on my servers, it won't count
against your disk quota. ;-P
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
On Wed, Apr 16, 2008 at 7:59 AM, Andrew Ballard <aballardgmail.com> wrote:
> In addition to the added time, aren't there any problems with race
> conditions if two users try to create a file at the same time and each
> user's script tries to clean the same files at the same time?
ergo, the need to name the files differently; or provide a separate
namespace, such as a per-user sub-directory.
-nathan
attached mail follows:
On Wed, Apr 16, 2008 at 9:59 AM, Nathan Nobbe <quickshiftingmail.com> wrote:
>
> well since i dont have your service dan, im filling in blanks over here;
> but, do users get to determine the name of the files that get created by
> this script, or at least rename them; that could be very beneficial.
Invalid. You went from a statement, to the posing of a question,
to a semi-colonic (pardon the pun!) statement again. :-D
In any case, yes: the filename can be determined by the user at
the time of the function call. And the file can be renamed, as well;
it's placed wherever the user specifies (provided he or she has
subsequent permission to write to the location, of course).
> run on sentence #2 ;D
You are the weakest link. Goodbye!
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
On Wed, Apr 16, 2008 at 8:02 AM, Daniel Brown <parasanegmail.com> wrote:
> On Wed, Apr 16, 2008 at 9:56 AM, Nathan Nobbe <quickshiftingmail.com>
> wrote:
> >
> > it sounds like thats what theyre talking about doing...
> >
> [snip!]
> >
> > that way, you could get rid of them almost as quickly as they are
> created;
> > you wont be overwriting any files for different users, and you have the
> > garuantee that the sound bytes will no longer be required for use by the
> > clients. because theyve gone to another page ;) and you eliminate any
> > issue about knowing when the file has been completely downloaded by the
> > client.
>
> A great idea if the audio is only being used as an embedded object
> within a page. However, if a developer wants to use the functions to
> create audio clips for another reason, the session expiration won't
> work.
>
fair enough; but i did address all the aforementioned concerns. you threw
that one at me from left field :D
>
> Conversely, if a developer wants to use the functions to create
> audio clips for another reason, he or she will probably already have a
> way of cleaning that up, as well! ;-P
>
> I suppose that further validates the idea.
>
> > i would still consider a cron as a cleanup script tho...
>
> I still think it's the best and most responsible way. However,
> I'm also kicking around the idea of giving each member a larger
> private tmp directory, that can then be cleaned out using Thiago's
> idea - anything older than n hours is deleted by a function run from a
> root cron.
i thought this was pretty much what tedd was doing in the first place. i
mean what else do you do w/ a cleanup script? you have to clean the files
that are no longer in use..
And no, to those of you who are on my servers, it won't count
> against your disk quota. ;-P
good man.
-nathan
attached mail follows:
On Wed, Apr 16, 2008 at 9:59 AM, Andrew Ballard <aballardgmail.com> wrote:
>
> In addition to the added time, aren't there any problems with race
> conditions if two users try to create a file at the same time and each
> user's script tries to clean the same files at the same time?
With output error buffering (or 'rm -f {FILENAME}') there wouldn't
be. If a tree falls in the woods and no one is there to hear it, it
doesn't make a sound at all. Such is the same with error reporting:
if I'm not told an error occurred, then it didn't. Ignorance is
bliss. ;-P
In reality, you're correct. If the files have the same names, are
in the same location, and are set for removal at the same time, then
yes.
--
</Daniel P. Brown>
Ask me about:
Dedicated servers starting $59.99/mo., VPS starting $19.99/mo.,
and shared hosting starting $2.50/mo.
Unmanaged, managed, and fully-managed!
attached mail follows:
On Wed, Apr 16, 2008 at 10:05 AM, Nathan Nobbe <quickshiftingmail.com> wrote:
> On Wed, Apr 16, 2008 at 7:59 AM, Andrew Ballard <aballardgmail.com> wrote:
>
> > In addition to the added time, aren't there any problems with race
> > conditions if two users try to create a file at the same time and each
> > user's script tries to clean the same files at the same time?
>
> ergo, the need to name the files differently; or provide a separate
> namespace, such as a per-user sub-directory.
>
> -nathan
>
It's a start, but what about a user who never returns? You still want
some way to clean out those old files, and I think that's the approach
Thiago was presenting by purging all files older than X
days/hours/minutes. Such a script would have to scan the entire space
regardless of "namespace." I think this points us toward cron rather
than potentially having two simultaneous client processes both looping
through the same directory trying to delete files.
Andrew
attached mail follows:
On Wed, Apr 16, 2008 at 8:12 AM, Daniel Brown <parasanegmail.com> wrote:
> On Wed, Apr 16, 2008 at 10:05 AM, Nathan Nobbe <quickshiftingmail.com>
> wrote:
> > On Wed, Apr 16, 2008 at 7:59 AM, Andrew Ballard <aballardgmail.com>
> wrote:
> >
> > > In addition to the added time, aren't there any problems with race
> > > conditions if two users try to create a file at the same time and
> each
> > > user's script tries to clean the same files at the same time?
> >
> >
> > ergo, the need to name the files differently; or provide a separate
> > namespace, such as a per-user sub-directory.
>
> Do you want to play around with a quick demo account? I can set
> you up with temporary access to SSH and the web if you want to see
> what we're talking about.
sure, why not; but ill not let you lure me into a full hosting deal. ive
got my own systems, atm.
-nathan
attached mail follows:
On Wed, Apr 16, 2008 at 10:13 AM, Nathan Nobbe <quickshiftingmail.com> wrote:
> On Wed, Apr 16, 2008 at 8:07 AM, Daniel Brown <parasanegmail.com> wrote:
>
> > You are the weakest link. Goodbye!
>
>