| checking for audio playing ??? [message #183459] |
Sun, 27 October 2013 14:58  |
Mr Oldies
Messages: 241
Registered: October 2013
Karma: 0
|
Senior Member |
|
|
Does php have any method of checking to determine if audio is playing or
not?
While I'm using the JWplayer on my site, I don't like the way the flash
handles the scrolling.
What I want to do is, have my own external playlist and do a continous play
loop. So that when item 1 is playing, that division in the list is
highlighted. When item 1 stops, drops to item 2 and item 2 plays.
All I need is the audio player to play the corresponding item.
|
|
|
|
| Re: checking for audio playing ??? [message #183460 is a reply to message #183459] |
Sun, 27 October 2013 15:45  |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
richard:
> Does php have any method of checking to determine if audio is playing or
> not?
In your case PHP runs on the *server*, but the audio is playing in the
*browser*, so the answer is no.
You would have to employ client-side scripting to determine whether the
audio is playing, but that is OT in this newsgroup.
--
Christoph M. Becker
|
|
|
|
| Re: checking for audio playing ??? [message #183461 is a reply to message #183460] |
Sun, 27 October 2013 16:01 |
Mr Oldies
Messages: 241
Registered: October 2013
Karma: 0
|
Senior Member |
|
|
On Sun, 27 Oct 2013 16:45:50 +0100, Christoph Michael Becker wrote:
> richard:
>
>> Does php have any method of checking to determine if audio is playing or
>> not?
>
> In your case PHP runs on the *server*, but the audio is playing in the
> *browser*, so the answer is no.
>
> You would have to employ client-side scripting to determine whether the
> audio is playing, but that is OT in this newsgroup.
True.
thanks
|
|
|
|
| Re: checking for audio playing ??? [message #183463 is a reply to message #183459] |
Sun, 27 October 2013 17:53 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sun, 27 Oct 2013 10:58:15 -0400, richard wrote:
> Does php have any method of checking to determine if audio is playing or
> not?
This is the sort of question which demonstrates that, although many
people have tried to explain the difference between server and client to
you on several occasions over many years, you still have no appreciation
whatsoever of the separation of functionality between the web server and
the web client.
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
|
|
| Re: checking for audio playing ??? [message #183465 is a reply to message #183463] |
Sun, 27 October 2013 18:24 |
Mr Oldies
Messages: 241
Registered: October 2013
Karma: 0
|
Senior Member |
|
|
On Sun, 27 Oct 2013 17:53:37 +0000 (UTC), Denis McMahon wrote:
> On Sun, 27 Oct 2013 10:58:15 -0400, richard wrote:
>
>> Does php have any method of checking to determine if audio is playing or
>> not?
>
> This is the sort of question which demonstrates that, although many
> people have tried to explain the difference between server and client to
> you on several occasions over many years, you still have no appreciation
> whatsoever of the separation of functionality between the web server and
> the web client.
So then when an mp3 file is downloaded, is it downloaded entirely into the
browser BEFORE the audio is played?
Then why do we have buffering?
The server almost has to know when any given mp3 file is being played.
|
|
|
|
| Re: checking for audio playing ??? [message #183466 is a reply to message #183465] |
Sun, 27 October 2013 18:38 |
Doug Miller
Messages: 171
Registered: August 2011
Karma: 0
|
Senior Member |
|
|
richard <noreply(at)example(dot)com> wrote in news:a4mqn9voa0zs$.2gqi5acsdw6l$.dlg@
40tude.net:
> The server almost has to know when any given mp3 file is being played.
No.
The server *cannot* know when the file is being *played*. The server's knowledge is
limited to:
- the browser requests the mp3 file
- the server begins transmitting the file
- eventually, the transmission finishes
The server has no way to know what the browser does with the file during or after the
transmission. The browser may play the file, save it, import it into something else, or discard
it completely, and the server cannot tell the difference. All the server knows is "somebody
asked me to send a file, I'm sending it... I'm done sending it."
|
|
|
|
| Re: checking for audio playing ??? [message #183467 is a reply to message #183465] |
Sun, 27 October 2013 18:43 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
On 10/27/13, 2:24 PM, richard wrote:
> On Sun, 27 Oct 2013 17:53:37 +0000 (UTC), Denis McMahon wrote:
>
>> On Sun, 27 Oct 2013 10:58:15 -0400, richard wrote:
>>
>>> Does php have any method of checking to determine if audio is playing or
>>> not?
>>
>> This is the sort of question which demonstrates that, although many
>> people have tried to explain the difference between server and client to
>> you on several occasions over many years, you still have no appreciation
>> whatsoever of the separation of functionality between the web server and
>> the web client.
>
> So then when an mp3 file is downloaded, is it downloaded entirely into the
> browser BEFORE the audio is played?
> Then why do we have buffering?
> The server almost has to know when any given mp3 file is being played.
>
Nope, the client will ask for the parts of the file that it needs,
normally downloading a bit before offering to start, and maybe
continuing to download all before the play button is pressed, so the
server can not tell from the download request if the file has actually
been played or not. The server only sees the download request, which
won't indicate if it is being played or not, and in fact it is possible
that the whole file will be downloaded before played, and at some latter
point play might be pressed, which will not send any signal back to the
server, unless you program the player (in flash/javascript/whatever) to
send you a message. The one thing that is fairly certain is that the
player will almost certainly NOT be written in PHP, as PHP is normally a
server side language, and few clients will understand it.
|
|
|
|
| Re: checking for audio playing ??? [message #183489 is a reply to message #183467] |
Mon, 28 October 2013 02:22 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Richard Damon wrote:
> […] The one thing that is fairly certain is that the
> player will almost certainly NOT be written in PHP,
That much is true.
> as PHP is normally a server side language, and few clients will understand
> it.
A common misconception. *No* programming language is “normally” either
“server-side” or “client-side”.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7(at)news(dot)demon(dot)co(dot)uk> (2004)
|
|
|
|
| Re: checking for audio playing ??? [message #183490 is a reply to message #183489] |
Mon, 28 October 2013 09:49 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/27/2013 10:22 PM, Thomas 'PointedEars' Lahn wrote:
> Richard Damon wrote:
>
>> […] The one thing that is fairly certain is that the
>> player will almost certainly NOT be written in PHP,
>
> That much is true.
>
>> as PHP is normally a server side language, and few clients will understand
>> it.
>
> A common misconception. *No* programming language is “normally” either
> “server-side” or “client-side”.
>
>
> PointedEars
>
No, not in your world it isn't. But in the real world, it is.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: checking for audio playing ??? [message #183491 is a reply to message #183489] |
Mon, 28 October 2013 12:11 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
> Richard Damon wrote:
>
>> […] The one thing that is fairly certain is that the
>> player will almost certainly NOT be written in PHP,
>
> That much is true.
>
>> as PHP is normally a server side language, and few clients will understand
>> it.
>
> A common misconception. *No* programming language is “normally” either
> “server-side” or “client-side”.
>
>
> PointedEars
>
Clearly a falsehood. I would expect that at least 95% of PHP executions
are done via mod-php or php-cgi in response to a http request, and thus
be a "server side" operation. Yes, there are some invocations via cli
doing local calculations, which would be neither server or client side.
There are a few (comparatively) invocations of PHP scripts that will go
out and make a http request to another page, and these could be
considered "client side" if executed via cli, and are somewhat ambiguous
if executed via mod-php or php-cgi (they are doing both sorts of
actions, but since it is being done in response to an incoming request,
this would normally be considered "server side")
I know of no situation (but I suppose it is conceivable) where a user
browser downloads a page, which contains "client side" PHP code, fires
up a PHP interpreter, runs that code and gives the results to the user.
This is what MOST people would think of a "client side" language, and it
doesn't happen. Thus PHP in normally (not exclusively, as the cli script
that accesses an external page is arguably a client side action, but
relatively unusual) a server side language.
In the same way most EMCAScripts (commonly called javascript) are run
within a user browser, even if there does exist some other usages that
might be considered "server side", so it would be a language that is
normally client side.
Note that "normal" does not mean exclusively, but only means in most
common usage.
|
|
|
|
| Re: checking for audio playing ??? [message #183492 is a reply to message #183491] |
Mon, 28 October 2013 13:37 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Richard Damon wrote:
> On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>> Richard Damon wrote:
>>> […] The one thing that is fairly certain is that the
>>> player will almost certainly NOT be written in PHP,
>>
>> That much is true.
>>
>>> as PHP is normally a server side language, and few clients will
>>> understand it.
>>
>> A common misconception. *No* programming language is “normally” either
>> “server-side” or “client-side”.
>
> Clearly a falsehood.
By coincidence, I had just read this:
<http://jargon-file.org/archive/jargon-1.5.0.dos.txt>
| HANDWAVE
| 1. verb. To gloss over a complex point; to distract a listener; to
| support a (possibly actually valid) point with blatantly faulty logic.
| If someone starts a sentence with "Clearly..." or "Obviously..." or "It
| is self-evident that...", you can be sure he is about to handwave.
| The idea is that if you wave your hands at the right moment, the
| listener may be sufficiently distracted that he will not notice that
| what you have said is BOGUS. Alternatively, if a listener does object,
| you might try to dismiss the objection "with a wave of your hand".
> I would expect that at least 95% of PHP executions
> are done via mod-php or php-cgi in response to a http request, [tl;dr]
So even by your standards there are 5% left for “client-side” applications.
Please do not quote signatures.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
|
|
|
|
| Re: checking for audio playing ??? [message #183493 is a reply to message #183459] |
Mon, 28 October 2013 13:49 |
Beauregard T. Shagnas
Messages: 154
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
PointedEars wrote:
> Please do not quote signatures.
>
>
--> PointedEars <--
Begs the question: why don't you place it *below* your signature
delimiter if you don't want people to quote it?
--
-bts
-This space for rent, but the price is high
|
|
|
|
| Re: checking for audio playing ??? [message #183494 is a reply to message #183491] |
Mon, 28 October 2013 14:01 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/28/2013 8:11 AM, Richard Damon wrote:
> On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>> Richard Damon wrote:
>>
>>> […] The one thing that is fairly certain is that the
>>> player will almost certainly NOT be written in PHP,
>>
>> That much is true.
>>
>>> as PHP is normally a server side language, and few clients will understand
>>> it.
>>
>> A common misconception. *No* programming language is “normally” either
>> “server-side” or “client-side”.
>>
>>
>> PointedEars
>>
>
> Clearly a falsehood. I would expect that at least 95% of PHP executions
> are done via mod-php or php-cgi in response to a http request, and thus
> be a "server side" operation. Yes, there are some invocations via cli
> doing local calculations, which would be neither server or client side.
> There are a few (comparatively) invocations of PHP scripts that will go
> out and make a http request to another page, and these could be
> considered "client side" if executed via cli, and are somewhat ambiguous
> if executed via mod-php or php-cgi (they are doing both sorts of
> actions, but since it is being done in response to an incoming request,
> this would normally be considered "server side")
>
> I know of no situation (but I suppose it is conceivable) where a user
> browser downloads a page, which contains "client side" PHP code, fires
> up a PHP interpreter, runs that code and gives the results to the user.
> This is what MOST people would think of a "client side" language, and it
> doesn't happen. Thus PHP in normally (not exclusively, as the cli script
> that accesses an external page is arguably a client side action, but
> relatively unusual) a server side language.
>
> In the same way most EMCAScripts (commonly called javascript) are run
> within a user browser, even if there does exist some other usages that
> might be considered "server side", so it would be a language that is
> normally client side.
>
> Note that "normal" does not mean exclusively, but only means in most
> common usage.
>
Richard, you should understand. "Pointed Head" lives in his own little
world, not at all related to that of the rest of us.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: checking for audio playing ??? [message #183495 is a reply to message #183465] |
Mon, 28 October 2013 15:23 |
Denis McMahon
Messages: 634
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On Sun, 27 Oct 2013 14:24:25 -0400, richard wrote:
> So then when an mp3 file is downloaded, is it downloaded entirely into
> the browser BEFORE the audio is played?
> Then why do we have buffering?
> The server almost has to know when any given mp3 file is being played.
Not at all.
The server only knows that something on the client has asked for the file.
The server doesn't know if the file is playing or not.
Supposing I type:
wget http://richards_server/some_audio_file.mp3
How does your server tell whether I'm opening the file in an audio
editor, saving it to hard disk, streaming it over internet radio or
playing it on my speakers?
--
Denis McMahon, denismfmcmahon(at)gmail(dot)com
|
|
|
|
| Re: checking for audio playing ??? [message #183496 is a reply to message #183495] |
Mon, 28 October 2013 16:56 |
The Natural Philosoph
Messages: 993
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 28/10/13 15:23, Denis McMahon wrote:
> On Sun, 27 Oct 2013 14:24:25 -0400, richard wrote:
>
>> So then when an mp3 file is downloaded, is it downloaded entirely into
>> the browser BEFORE the audio is played?
>> Then why do we have buffering?
>> The server almost has to know when any given mp3 file is being played.
>
> Not at all.
>
> The server only knows that something on the client has asked for the file.
>
> The server doesn't know if the file is playing or not.
>
> Supposing I type:
>
> wget http://richards_server/some_audio_file.mp3
>
> How does your server tell whether I'm opening the file in an audio
> editor, saving it to hard disk, streaming it over internet radio or
> playing it on my speakers?
>
or directing it to /dev/null where it probably belongs...
--
Ineptocracy
(in-ep-toc’-ra-cy) – a system of government where the least capable to
lead are elected by the least capable of producing, and where the
members of society least likely to sustain themselves or succeed, are
rewarded with goods and services paid for by the confiscated wealth of a
diminishing number of producers.
|
|
|
|
| Re: checking for audio playing ??? [message #183497 is a reply to message #183459] |
Mon, 28 October 2013 18:36 |
Scott Johnson
Messages: 196
Registered: January 2012
Karma: 0
|
Senior Member |
|
|
On 10/28/2013 6:34 AM, Thomas 'PointedEars' Lahn wrote:
> Richard Damon wrote:
>
>> On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>>> Richard Damon wrote:
>>>> […] The one thing that is fairly certain is that the
>>>> player will almost certainly NOT be written in PHP,
>>>
>>> That much is true.
>>>
>>>> as PHP is normally a server side language, and few clients will
>>>> understand it.
>>>
>>> A common misconception. *No* programming language is “normally” either
>>> “server-side” or “client-side”.
>>
>> Clearly a falsehood.
>
> Clearly you have not read.
>
>> I would expect that at least 95% of PHP executions
>> are done via mod-php or php-cgi in response to a http request, [tl;dr]
>
> So even by your standards there are 5% left for “client-side” applications.
>
> Please do not quote signatures.
>
>
Extra quote added
> PointedEars
So 95% is not what you would consider a normal instance?
Scotty
|
|
|
|
| Re: checking for audio playing ??? [message #183499 is a reply to message #183459] |
Mon, 28 October 2013 19:02 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Am 27.10.2013 15:58, schrieb richard:
> Does php have any method of checking to determine if audio is playing or
> not?
No. Since PHP only executes scripts on server side it can not determine
anything which goes on on the client.
> While I'm using the JWplayer on my site, I don't like the way the flash
> handles the scrolling.
>
> What I want to do is, have my own external playlist and do a continous play
> loop. So that when item 1 is playing, that division in the list is
> highlighted. When item 1 stops, drops to item 2 and item 2 plays.
>
> All I need is the audio player to play the corresponding item.
This has to be handled using JavaScript or similar on the client side
and is out of scope of this newsgroup.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: checking for audio playing ??? [message #183502 is a reply to message #183459] |
Tue, 29 October 2013 01:29 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
On 10/28/13, 9:34 AM, Thomas 'PointedEars' Lahn wrote:
> Richard Damon wrote:
>
>> On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>>> Richard Damon wrote:
>>>> […] The one thing that is fairly certain is that the
>>>> player will almost certainly NOT be written in PHP,
>>>
>>> That much is true.
>>>
>>>> as PHP is normally a server side language, and few clients will
>>>> understand it.
>>>
>>> A common misconception. *No* programming language is “normally” either
>>> “server-side” or “client-side”.
>>
>> Clearly a falsehood.
>
> Clearly you have not read.
>
>> I would expect that at least 95% of PHP executions
>> are done via mod-php or php-cgi in response to a http request, [tl;dr]
>
> So even by your standards there are 5% left for “client-side” applications.
>
I consider 95% to be a reasonable definition for "normally". I will add
that I normally ignore what you say because normally you are just
spouting gibberish (as it seems here).
> Please do not quote signatures.
>
I don't, my reader automatically removes signatures from quotes, of
course if you put something before the signature delimiter, it ISN'T a
signature. For someone who likes to spout about what standards say, it
would make sense that you would follow them.
>
> PointedEars
>
|
|
|
|
| Re: checking for audio playing ??? [message #183505 is a reply to message #183502] |
Tue, 29 October 2013 11:18 |
Thomas 'PointedEars'
Messages: 701
Registered: October 2010
Karma: 0
|
Senior Member |
|
|
Richard Damon wrote:
> On 10/28/13, 9:34 AM, Thomas 'PointedEars' Lahn wrote:
>> Richard Damon wrote:
>>> On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Richard Damon wrote:
>>>> > […] The one thing that is fairly certain is that the
>>>> > player will almost certainly NOT be written in PHP,
>>>>
>>>> That much is true.
>>>>
>>>> > as PHP is normally a server side language, and few clients will
>>>> > understand it.
>>>>
>>>> A common misconception. *No* programming language is “normally” either
>>>> “server-side” or “client-side”.
>>>
>>> Clearly a falsehood.
>>
>> [superseded]
>>
>>> I would expect that at least 95% of PHP executions
>>> are done via mod-php or php-cgi in response to a http request, [tl;dr]
>>
>> So even by your standards there are 5% left for “client-side”
>> applications.
>
> I consider 95% to be a reasonable definition for "normally". I will add
> that I normally ignore what you say because normally you are just
> spouting gibberish (as it seems here).
Why do you reply to the canceled posting?
Your logic is flawed. “normally” is a weasel word. Much like with other
programming languages, there are applications of PHP that have nothing to do
with the client-server architecture. Apparently you do not know them. Rest
assured that your numbers are from *thin air*. OTOH, I did not expect a
reasonable, well-founded argument to begin with “Clearly”, as pointed out in
the posting that superseded the one you replied to.
>> Please do not quote signatures.
>
> I don't, my reader automatically removes signatures from quotes, of
> course if you put something before the signature delimiter, it ISN'T a
> signature. For someone who likes to spout about what standards say, it
> would make sense that you would follow them.
There is no standard about it; there is a recommendation (RFC 1855). Like
several other people on Usenet, I choose to interpret it differently, and to
write my signature above the signature delimiter when I have something else
in my (randomly chosen) .sig that exceeds the recommended limit of four
lines.
So you need your newsreader to think for you?
Score adjusted
PointedEars
--
Sometimes, what you learn is wrong. If those wrong ideas are close to the
root of the knowledge tree you build on a particular subject, pruning the
bad branches can sometimes cause the whole tree to collapse.
-- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom(at)94(dot)75(dot)214(dot)39>
|
|
|
|
| Re: checking for audio playing ??? [message #183515 is a reply to message #183489] |
Tue, 29 October 2013 19:10 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn, 2013-10-28 03:22:
> Richard Damon wrote:
>
>> […] The one thing that is fairly certain is that the
>> player will almost certainly NOT be written in PHP,
>
> That much is true.
>
>> as PHP is normally a server side language, and few clients will understand
>> it.
>
> A common misconception. *No* programming language is “normally” either
> “server-side” or “client-side”.
Historically PHP had *always* been targeted to be used on a server to
generate output for one or more clients delivered via HTTP. That's the
reason why there are modules for Apache, why PHP supports CGI and why
literally every book about PHP teaches how to create websites using PHP
and not how to build desktop applications using PHP.
Just because it is technically possible to set up a PHP runtime
environment literally anywhere and <http://gtk.php.net/> exists it does
not make PHP a language which is also be used on "client side". BTW -
the last update of <http://gtk.php.net/> dates back to August 2010...
The opposite is true for ECMAScript which is fact used "server side" and
"client side" as well also in real applications.
But for sure you can name some popular PHP based desktop applications
that prove it wrong, that PHP is *usually* only used "server side" - can
you?
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: checking for audio playing ??? [message #183516 is a reply to message #183459] |
Tue, 29 October 2013 19:12 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Thomas 'PointedEars' Lahn, 2013-10-28 14:34:
> Richard Damon wrote:
>
>> On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>>> Richard Damon wrote:
>>>> […] The one thing that is fairly certain is that the
>>>> player will almost certainly NOT be written in PHP,
>>>
>>> That much is true.
>>>
>>>> as PHP is normally a server side language, and few clients will
>>>> understand it.
>>>
>>> A common misconception. *No* programming language is “normally” either
>>> “server-side” or “client-side”.
>>
>> Clearly a falsehood.
>
> Clearly you have not read.
You neither - or din't you understand this statement:
Note that "normal" does not mean exclusively, but only means in most
common usage.
>> I would expect that at least 95% of PHP executions
>> are done via mod-php or php-cgi in response to a http request, [tl;dr]
>
> So even by your standards there are 5% left for “client-side” applications.
So what? Does this make PHP a language is is *not* most of the time used
for "server side" stuff?
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: checking for audio playing ??? [message #183520 is a reply to message #183516] |
Tue, 29 October 2013 20:21 |
Doug Miller
Messages: 171
Registered: August 2011
Karma: 0
|
Senior Member |
|
|
Arno Welzel <usenet(at)arnowelzel(dot)de> wrote in news:527008B0(dot)8020201(at)arnowelzel(dot)de:
> Thomas 'PointedEars' Lahn, 2013-10-28 14:34:
>
>> Richard Damon wrote:
>>
>>> On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Richard Damon wrote:
>>>> > […] The one thing that is fairly certain is that the
>>>> > player will almost certainly NOT be written in PHP,
>>>>
>>>> That much is true.
>>>>
>>>> > as PHP is normally a server side language, and few clients will
>>>> > understand it.
>>>>
>>>> A common misconception. *No* programming language is “normally” either
>>>> “server-side” or “client-side”.
>>>
>>> Clearly a falsehood.
>>
>> Clearly you have not read.
>
> You neither - or din't you understand this statement:
>
> Note that "normal" does not mean exclusively, but only means in most
> common usage.
>
>>> I would expect that at least 95% of PHP executions
>>> are done via mod-php or php-cgi in response to a http request, [tl;dr]
>>
>> So even by your standards there are 5% left for “client-side” applications.
>
> So what? Does this make PHP a language is is *not* most of the time used
> for "server side" stuff?
>
Arno, since you're coming from a .de top-level domain, perhaps you should write to
PointedHead auf Deutsch. He'd [probably] understand you better: that's his native
language, not English -- and as someone whose native language *is* English, I have
observed that PointedHead does not understand it as well as he thinks he does. This
appears to an example of such.
|
|
|
|
| server-side vs.client-side (was: checking for audio playing ???) [message #183521 is a reply to message #183515] |
Tue, 29 October 2013 20:45 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Arno Welzel wrote:
> Thomas 'PointedEars' Lahn, 2013-10-28 03:22:
>
>> Richard Damon wrote:
>>
>>> […] The one thing that is fairly certain is that the
>>> player will almost certainly NOT be written in PHP,
>>
>> That much is true.
>>
>>> as PHP is normally a server side language, and few clients will understand
>>> it.
>>
>> A common misconception. *No* programming language is “normally” either
>> “server-side” or “client-side”.
>
> Historically PHP had *always* been targeted to be used on a server to
> generate output for one or more clients delivered via HTTP. That's the
> reason why there are modules for Apache, why PHP supports CGI and why
> literally every book about PHP teaches how to create websites using PHP
> and not how to build desktop applications using PHP.
>
> Just because it is technically possible to set up a PHP runtime
> environment literally anywhere and <http://gtk.php.net/> exists it does
> not make PHP a language which is also be used on "client side". BTW -
> the last update of <http://gtk.php.net/> dates back to August 2010...
>
> The opposite is true for ECMAScript which is fact used "server side" and
> "client side" as well also in real applications.
>
> But for sure you can name some popular PHP based desktop applications
> that prove it wrong, that PHP is *usually* only used "server side" - can
> you?
It seems you're not taken into account command line applications, for
which PHP is well suited.[1] These often run outside of any
client-server context, such as phing and phpunit (which I am using
"every" day), for instance.
[1] <http://php.net/manual/en/features.commandline.php>
--
Christoph M. Becker
|
|
|
|
| Re: server-side vs.client-side [message #183526 is a reply to message #183521] |
Wed, 30 October 2013 00:54 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/29/2013 4:45 PM, Christoph Michael Becker wrote:
> Arno Welzel wrote:
>
>> Thomas 'PointedEars' Lahn, 2013-10-28 03:22:
>>
>>> Richard Damon wrote:
>>>
>>>> […] The one thing that is fairly certain is that the
>>>> player will almost certainly NOT be written in PHP,
>>>
>>> That much is true.
>>>
>>>> as PHP is normally a server side language, and few clients will understand
>>>> it.
>>>
>>> A common misconception. *No* programming language is “normally” either
>>> “server-side” or “client-side”.
>>
>> Historically PHP had *always* been targeted to be used on a server to
>> generate output for one or more clients delivered via HTTP. That's the
>> reason why there are modules for Apache, why PHP supports CGI and why
>> literally every book about PHP teaches how to create websites using PHP
>> and not how to build desktop applications using PHP.
>>
>> Just because it is technically possible to set up a PHP runtime
>> environment literally anywhere and <http://gtk.php.net/> exists it does
>> not make PHP a language which is also be used on "client side". BTW -
>> the last update of <http://gtk.php.net/> dates back to August 2010...
>>
>> The opposite is true for ECMAScript which is fact used "server side" and
>> "client side" as well also in real applications.
>>
>> But for sure you can name some popular PHP based desktop applications
>> that prove it wrong, that PHP is *usually* only used "server side" - can
>> you?
>
> It seems you're not taken into account command line applications, for
> which PHP is well suited.[1] These often run outside of any
> client-server context, such as phing and phpunit (which I am using
> "every" day), for instance.
>
> [1] <http://php.net/manual/en/features.commandline.php>
>
Sure, there are command line applications. But what percentage of the
PHP scripts out there fall into this case?
You're as bad as Pointed Head. You don't understand what the term
"Normal" means. Maybe you're in the same alternate universe he is.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: server-side vs.client-side [message #183532 is a reply to message #183526] |
Wed, 30 October 2013 02:18 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 10/29/2013 4:45 PM, Christoph Michael Becker wrote:
>> Arno Welzel wrote:
>>
>>> Thomas 'PointedEars' Lahn, 2013-10-28 03:22:
>>>
>>>> Richard Damon wrote:
>>>>
>>>> > […] The one thing that is fairly certain is that the
>>>> > player will almost certainly NOT be written in PHP,
>>>>
>>>> That much is true.
>>>>
>>>> > as PHP is normally a server side language, and few clients will
>>>> > understand
>>>> > it.
>>>>
>>>> A common misconception. *No* programming language is “normally” either
>>>> “server-side” or “client-side”.
>>>
>>> Historically PHP had *always* been targeted to be used on a server to
>>> generate output for one or more clients delivered via HTTP. That's the
>>> reason why there are modules for Apache, why PHP supports CGI and why
>>> literally every book about PHP teaches how to create websites using PHP
>>> and not how to build desktop applications using PHP.
>>>
>>> Just because it is technically possible to set up a PHP runtime
>>> environment literally anywhere and <http://gtk.php.net/> exists it does
>>> not make PHP a language which is also be used on "client side". BTW -
>>> the last update of <http://gtk.php.net/> dates back to August 2010...
>>>
>>> The opposite is true for ECMAScript which is fact used "server side" and
>>> "client side" as well also in real applications.
>>>
>>> But for sure you can name some popular PHP based desktop applications
>>> that prove it wrong, that PHP is *usually* only used "server side" - can
>>> you?
>>
>> It seems you're not taken into account command line applications, for
>> which PHP is well suited.[1] These often run outside of any
>> client-server context, such as phing and phpunit (which I am using
>> "every" day), for instance.
>>
>> [1] <http://php.net/manual/en/features.commandline.php>
>>
>
> Sure, there are command line applications. But what percentage of the
> PHP scripts out there fall into this case?
Thomas said (see above for reference):
| *No* programming language is “normally” either
| “server-side” or “client-side”.
Pointing out a single PHP application that runs neither "server-side"
nor "client-side" proves this statement wrt. PHP (that doesn't prove the
argument, though, but one can easily imagine any programming language to
be used outside a client-server context). I pointed out two such
applications.
> You're as bad as Pointed Head. You don't understand what the term
> "Normal" means. Maybe you're in the same alternate universe he is.
You may want to reconsider this statement. :)
--
Christoph M. Becker
|
|
|
|
| Re: server-side vs.client-side [message #183533 is a reply to message #183532] |
Wed, 30 October 2013 02:31 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/29/2013 10:18 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 10/29/2013 4:45 PM, Christoph Michael Becker wrote:
>>> Arno Welzel wrote:
>>>
>>>> Thomas 'PointedEars' Lahn, 2013-10-28 03:22:
>>>>
>>>> > Richard Damon wrote:
>>>> >
>>>> >> […] The one thing that is fairly certain is that the
>>>> >> player will almost certainly NOT be written in PHP,
>>>> >
>>>> > That much is true.
>>>> >
>>>> >> as PHP is normally a server side language, and few clients will
>>>> >> understand
>>>> >> it.
>>>> >
>>>> > A common misconception. *No* programming language is “normally” either
>>>> > “server-side” or “client-side”.
>>>>
>>>> Historically PHP had *always* been targeted to be used on a server to
>>>> generate output for one or more clients delivered via HTTP. That's the
>>>> reason why there are modules for Apache, why PHP supports CGI and why
>>>> literally every book about PHP teaches how to create websites using PHP
>>>> and not how to build desktop applications using PHP.
>>>>
>>>> Just because it is technically possible to set up a PHP runtime
>>>> environment literally anywhere and <http://gtk.php.net/> exists it does
>>>> not make PHP a language which is also be used on "client side". BTW -
>>>> the last update of <http://gtk.php.net/> dates back to August 2010...
>>>>
>>>> The opposite is true for ECMAScript which is fact used "server side" and
>>>> "client side" as well also in real applications.
>>>>
>>>> But for sure you can name some popular PHP based desktop applications
>>>> that prove it wrong, that PHP is *usually* only used "server side" - can
>>>> you?
>>>
>>> It seems you're not taken into account command line applications, for
>>> which PHP is well suited.[1] These often run outside of any
>>> client-server context, such as phing and phpunit (which I am using
>>> "every" day), for instance.
>>>
>>> [1] <http://php.net/manual/en/features.commandline.php>
>>>
>>
>> Sure, there are command line applications. But what percentage of the
>> PHP scripts out there fall into this case?
>
> Thomas said (see above for reference):
>
> | *No* programming language is “normally” either
> | “server-side” or “client-side”.
>
> Pointing out a single PHP application that runs neither "server-side"
> nor "client-side" proves this statement wrt. PHP (that doesn't prove the
> argument, though, but one can easily imagine any programming language to
> be used outside a client-server context). I pointed out two such
> applications.
>
"Normal" does not mean ALWAYS. It means "usual usage", i.e. "more than
50% of the time". The statement is correct. You are not.
>> You're as bad as Pointed Head. You don't understand what the term
>> "Normal" means. Maybe you're in the same alternate universe he is.
>
> You may want to reconsider this statement. :)
>
Not at all. I stand by it completely.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: server-side vs.client-side [message #183538 is a reply to message #183521] |
Wed, 30 October 2013 08:09 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker, 2013-10-29 21:45:
> Arno Welzel wrote:
>
>> Thomas 'PointedEars' Lahn, 2013-10-28 03:22:
>>
>>> Richard Damon wrote:
>>>
>>>> […] The one thing that is fairly certain is that the
>>>> player will almost certainly NOT be written in PHP,
>>>
>>> That much is true.
>>>
>>>> as PHP is normally a server side language, and few clients will understand
>>>> it.
>>>
>>> A common misconception. *No* programming language is “normally” either
>>> “server-side” or “client-side”.
>>
>> Historically PHP had *always* been targeted to be used on a server to
>> generate output for one or more clients delivered via HTTP. That's the
>> reason why there are modules for Apache, why PHP supports CGI and why
>> literally every book about PHP teaches how to create websites using PHP
>> and not how to build desktop applications using PHP.
[...]
> It seems you're not taken into account command line applications, for
> which PHP is well suited.[1] These often run outside of any
> client-server context, such as phing and phpunit (which I am using
> "every" day), for instance.
>
> [1] <http://php.net/manual/en/features.commandline.php>
Indeed - I did not include this. Thanks for the addition.
But even though it is possible to use PHP in this way (and some PHP
applications even include scripts which should be used as command line
scripts only - e.g. the Piwik statistics archiver) I would not call PHP
the typical universal scripting language which is also used to run websites.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: server-side vs.client-side [message #183539 is a reply to message #183532] |
Wed, 30 October 2013 08:20 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker, 2013-10-30 03:18:
> Jerry Stuckle wrote:
[...]
>> Sure, there are command line applications. But what percentage of the
>> PHP scripts out there fall into this case?
>
> Thomas said (see above for reference):
>
> | *No* programming language is “normally” either
> | “server-side” or “client-side”.
>
> Pointing out a single PHP application that runs neither "server-side"
> nor "client-side" proves this statement wrt. PHP (that doesn't prove the
> argument, though, but one can easily imagine any programming language to
> be used outside a client-server context). I pointed out two such
> applications.
Ok - then you and Thomas would see this statement in the same manner:
"Screw drivers are normally used to tighten or loosen screws"
And you would point out, that a screw driver can also be used to stir a
cup of coffee or as a lever to open the lid of a can - so it is wrong to
assume that a screw driver is "normally" a tool to handle screws.
Well - yes - i'm exaggerating a bit. But hopefully you will get the point.
Even if it is *also* possible to use PHP in different ways and not just
as a scripting language in web servers it is easier for beginners to
*define* it as a "server side" language in contrast to JavaScript which
is usually used on "client side" within the browser, since most PHP
applications in the real world *are* this way.
Just remember the questions in this newsgroup if PHP can determine an
audio file playing in the browser (and some other similar questions) -
this confusion also comes from statements like yours and Thomas which
may be correct in technical terms - but it doesn't help people with
lesser knowledge and only increases the confusion about concepts and the
different aspects of web based applications. You have to separate these
two sides of server and client and consider carefully what things happen
on which side.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: server-side vs.client-side [message #183545 is a reply to message #183539] |
Wed, 30 October 2013 18:04 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Arno Welzel wrote:
> Christoph Michael Becker, 2013-10-30 03:18:
>
>> Jerry Stuckle wrote:
> [...]
>>> Sure, there are command line applications. But what percentage of the
>>> PHP scripts out there fall into this case?
>>
>> Thomas said (see above for reference):
>>
>> | *No* programming language is “normally” either
>> | “server-side” or “client-side”.
>>
>> Pointing out a single PHP application that runs neither "server-side"
>> nor "client-side" proves this statement wrt. PHP (that doesn't prove the
>> argument, though, but one can easily imagine any programming language to
>> be used outside a client-server context). I pointed out two such
>> applications.
>
> Ok - then you and Thomas would see this statement in the same manner:
>
> "Screw drivers are normally used to tighten or loosen screws"
No. To stick with the screwdriver metaphor, Thomas' statement would be:
"No screwdriver is "normally" either used to tighten or to loosen screws."
And that one is true, isn't it.
> And you would point out, that a screw driver can also be used to stir a
> cup of coffee or as a lever to open the lid of a can - so it is wrong to
> assume that a screw driver is "normally" a tool to handle screws.
>
> Well - yes - i'm exaggerating a bit. But hopefully you will get the point.
I had already gotten this point.
> Even if it is *also* possible to use PHP in different ways and not just
> as a scripting language in web servers it is easier for beginners to
> *define* it as a "server side" language in contrast to JavaScript which
> is usually used on "client side" within the browser, since most PHP
> applications in the real world *are* this way.
This newsgroup is not espicially aimed to beginners.
> Just remember the questions in this newsgroup if PHP can determine an
> audio file playing in the browser (and some other similar questions) -
> this confusion also comes from statements like yours and Thomas which
> may be correct in technical terms - but it doesn't help people with
> lesser knowledge and only increases the confusion about concepts and the
> different aspects of web based applications. You have to separate these
> two sides of server and client and consider carefully what things happen
> on which side.
I had already posted this in reply to the OP in
<526d351e$0$9523$9b4e6d93(at)newsspool1(dot)arcor-online(dot)net>
--
Christoph M. Becker
|
|
|
|
| Re: server-side vs.client-side [message #183547 is a reply to message #183545] |
Wed, 30 October 2013 18:58 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/30/2013 2:04 PM, Christoph Michael Becker wrote:
> Arno Welzel wrote:
>
>> Christoph Michael Becker, 2013-10-30 03:18:
>>
>>> Jerry Stuckle wrote:
>> [...]
>>>> Sure, there are command line applications. But what percentage of the
>>>> PHP scripts out there fall into this case?
>>>
>>> Thomas said (see above for reference):
>>>
>>> | *No* programming language is “normally” either
>>> | “server-side” or “client-side”.
>>>
>>> Pointing out a single PHP application that runs neither "server-side"
>>> nor "client-side" proves this statement wrt. PHP (that doesn't prove the
>>> argument, though, but one can easily imagine any programming language to
>>> be used outside a client-server context). I pointed out two such
>>> applications.
>>
>> Ok - then you and Thomas would see this statement in the same manner:
>>
>> "Screw drivers are normally used to tighten or loosen screws"
>
> No. To stick with the screwdriver metaphor, Thomas' statement would be:
>
> "No screwdriver is "normally" either used to tighten or to loosen screws."
>
> And that one is true, isn't it.
>
>> And you would point out, that a screw driver can also be used to stir a
>> cup of coffee or as a lever to open the lid of a can - so it is wrong to
>> assume that a screw driver is "normally" a tool to handle screws.
>>
>> Well - yes - i'm exaggerating a bit. But hopefully you will get the point.
>
> I had already gotten this point.
>
>> Even if it is *also* possible to use PHP in different ways and not just
>> as a scripting language in web servers it is easier for beginners to
>> *define* it as a "server side" language in contrast to JavaScript which
>> is usually used on "client side" within the browser, since most PHP
>> applications in the real world *are* this way.
>
> This newsgroup is not espicially aimed to beginners.
>
>> Just remember the questions in this newsgroup if PHP can determine an
>> audio file playing in the browser (and some other similar questions) -
>> this confusion also comes from statements like yours and Thomas which
>> may be correct in technical terms - but it doesn't help people with
>> lesser knowledge and only increases the confusion about concepts and the
>> different aspects of web based applications. You have to separate these
>> two sides of server and client and consider carefully what things happen
>> on which side.
>
> I had already posted this in reply to the OP in
> <526d351e$0$9523$9b4e6d93(at)newsspool1(dot)arcor-online(dot)net>
>
Christopher,
One question - since both you and Thomas seem to be from Germany, and
have the same misunderstanding of the word "normally", what does
"normally" translate to in German? What does it mean?
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: server-side vs.client-side [message #183548 is a reply to message #183547] |
Wed, 30 October 2013 19:54 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> One question - since both you and Thomas seem to be from Germany, and
> have the same misunderstanding of the word "normally", what does
> "normally" translate to in German? What does it mean?
In Germany it is "normalerweise"/"üblicherweise", what means as much
usually. Anyway, a misunderstanding of the term "normally" is not the
problem here for me. In my opinion, it is correct to state: "PHP is
normally (usually, most often etc.) used on a server (for server-side
programming)."
It is as well correct to state: "No programming language is normally
either server-side or client-side." Otherwise it would mean, that there
are programming languages that couldn't be used outside of a
client-server context.
--
Christoph M. Becker
|
|
|
|
| Re: server-side vs.client-side [message #183550 is a reply to message #183548] |
Wed, 30 October 2013 20:21 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/30/2013 3:54 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> One question - since both you and Thomas seem to be from Germany, and
>> have the same misunderstanding of the word "normally", what does
>> "normally" translate to in German? What does it mean?
>
> In Germany it is "normalerweise"/"üblicherweise", what means as much
> usually. Anyway, a misunderstanding of the term "normally" is not the
> problem here for me. In my opinion, it is correct to state: "PHP is
> normally (usually, most often etc.) used on a server (for server-side
> programming)."
>
> It is as well correct to state: "No programming language is normally
> either server-side or client-side." Otherwise it would mean, that there
> are programming languages that couldn't be used outside of a
> client-server context.
>
But "normally" in English doesn't mean it can't be used otherwise - it
just means most of the time it is not.
For instance, people "normally" drive their cars on roads. But that
does not mean they can't take them off-road (obviously the conditions
must be right or you get stuck :) ). As an example, Daytona Beach,
Florida has very hard packed sand. It is not at all unusual to see
people driving regular street cars on the beach.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: server-side vs.client-side [message #183551 is a reply to message #183550] |
Wed, 30 October 2013 20:55 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Jerry Stuckle wrote:
> On 10/30/2013 3:54 PM, Christoph Michael Becker wrote:
>> Jerry Stuckle wrote:
>>
>>> One question - since both you and Thomas seem to be from Germany, and
>>> have the same misunderstanding of the word "normally", what does
>>> "normally" translate to in German? What does it mean?
>>
>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>> usually. Anyway, a misunderstanding of the term "normally" is not the
>> problem here for me. In my opinion, it is correct to state: "PHP is
>> normally (usually, most often etc.) used on a server (for server-side
>> programming)."
>>
>> It is as well correct to state: "No programming language is normally
>> either server-side or client-side." Otherwise it would mean, that there
>> are programming languages that couldn't be used outside of a
>> client-server context.
>>
>
> But "normally" in English doesn't mean it can't be used otherwise - it
> just means most of the time it is not.
That is the same in German. However, one *might* argue that "normally"
stems from "norm", and so should be used only in this strict sense. I
do not, and have not done.
> For instance, people "normally" drive their cars on roads. But that
> does not mean they can't take them off-road (obviously the conditions
> must be right or you get stuck :) ). As an example, Daytona Beach,
> Florida has very hard packed sand. It is not at all unusual to see
> people driving regular street cars on the beach.
So one may say: "No car is normally either driven on a road or on a
beach". Besides that a car might be driven on grassland (the point I
had already made explicit), it may be driven on a road as well as on a
beach (not simultaneously, though, but the same programming language may
well be used simultaneously on the server as well as on the client).
--
Christoph M. Becker
|
|
|
|
| Re: server-side vs.client-side [message #183552 is a reply to message #183551] |
Wed, 30 October 2013 21:07 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/30/2013 4:55 PM, Christoph Michael Becker wrote:
> Jerry Stuckle wrote:
>
>> On 10/30/2013 3:54 PM, Christoph Michael Becker wrote:
>>> Jerry Stuckle wrote:
>>>
>>>> One question - since both you and Thomas seem to be from Germany, and
>>>> have the same misunderstanding of the word "normally", what does
>>>> "normally" translate to in German? What does it mean?
>>>
>>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>>> usually. Anyway, a misunderstanding of the term "normally" is not the
>>> problem here for me. In my opinion, it is correct to state: "PHP is
>>> normally (usually, most often etc.) used on a server (for server-side
>>> programming)."
>>>
>>> It is as well correct to state: "No programming language is normally
>>> either server-side or client-side." Otherwise it would mean, that there
>>> are programming languages that couldn't be used outside of a
>>> client-server context.
>>>
>>
>> But "normally" in English doesn't mean it can't be used otherwise - it
>> just means most of the time it is not.
>
> That is the same in German. However, one *might* argue that "normally"
> stems from "norm", and so should be used only in this strict sense. I
> do not, and have not done.
>
>> For instance, people "normally" drive their cars on roads. But that
>> does not mean they can't take them off-road (obviously the conditions
>> must be right or you get stuck :) ). As an example, Daytona Beach,
>> Florida has very hard packed sand. It is not at all unusual to see
>> people driving regular street cars on the beach.
>
> So one may say: "No car is normally either driven on a road or on a
> beach". Besides that a car might be driven on grassland (the point I
> had already made explicit), it may be driven on a road as well as on a
> beach (not simultaneously, though, but the same programming language may
> well be used simultaneously on the server as well as on the client).
>
No, at least in English, that would not be correct, because cars are
driven on roads probably > 99% of the time (at least in the U.S.). That
is their "normal usage".
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| Re: server-side vs.client-side [message #183556 is a reply to message #183548] |
Thu, 31 October 2013 08:40 |
Arno Welzel
Messages: 317
Registered: October 2011
Karma: 0
|
Senior Member |
|
|
Christoph Michael Becker, 2013-10-30 20:54:
> Jerry Stuckle wrote:
>
>> One question - since both you and Thomas seem to be from Germany, and
>> have the same misunderstanding of the word "normally", what does
>> "normally" translate to in German? What does it mean?
>
> In Germany it is "normalerweise"/"üblicherweise", what means as much
> usually. Anyway, a misunderstanding of the term "normally" is not the
> problem here for me. In my opinion, it is correct to state: "PHP is
> normally (usually, most often etc.) used on a server (for server-side
> programming)."
>
> It is as well correct to state: "No programming language is normally
> either server-side or client-side." Otherwise it would mean, that there
> are programming languages that couldn't be used outside of a
> client-server context.
Exactly *this* is the wrong assumption, what "normally" means in this
context. It does *NOT* mean that a language can *never* be used in other
ways - it only says that is the the most common use of it.
--
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
|
|
|
|
| Re: server-side vs.client-side [message #183563 is a reply to message #183556] |
Thu, 31 October 2013 22:03 |
Christoph Michael Bec
Messages: 207
Registered: June 2013
Karma: 0
|
Senior Member |
|
|
Arno Welzel wrote:
> Christoph Michael Becker, 2013-10-30 20:54:
>
>> Jerry Stuckle wrote:
>>
>>> One question - since both you and Thomas seem to be from Germany, and
>>> have the same misunderstanding of the word "normally", what does
>>> "normally" translate to in German? What does it mean?
>>
>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>> usually. Anyway, a misunderstanding of the term "normally" is not the
>> problem here for me. In my opinion, it is correct to state: "PHP is
>> normally (usually, most often etc.) used on a server (for server-side
>> programming)."
>>
>> It is as well correct to state: "No programming language is normally
>> either server-side or client-side." Otherwise it would mean, that there
>> are programming languages that couldn't be used outside of a
>> client-server context.
>
> Exactly *this* is the wrong assumption, what "normally" means in this
> context. It does *NOT* mean that a language can *never* be used in other
> ways - it only says that is the the most common use of it.
I thought there is the same difference between
"No programming language is normally either server-side or
client-side."
and
"No programming language is either normally server-side
or normally client-side."
as it is in German. Apparently, I was mistaken.
--
Christoph M. Becker
|
|
|
|
| Re: server-side vs.client-side [message #183565 is a reply to message #183563] |
Fri, 01 November 2013 00:38 |
Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
|
Senior Member |
|
|
On 10/31/2013 6:03 PM, Christoph Michael Becker wrote:
> Arno Welzel wrote:
>
>> Christoph Michael Becker, 2013-10-30 20:54:
>>
>>> Jerry Stuckle wrote:
>>>
>>>> One question - since both you and Thomas seem to be from Germany, and
>>>> have the same misunderstanding of the word "normally", what does
>>>> "normally" translate to in German? What does it mean?
>>>
>>> In Germany it is "normalerweise"/"üblicherweise", what means as much
>>> usually. Anyway, a misunderstanding of the term "normally" is not the
>>> problem here for me. In my opinion, it is correct to state: "PHP is
>>> normally (usually, most often etc.) used on a server (for server-side
>>> programming)."
>>>
>>> It is as well correct to state: "No programming language is normally
>>> either server-side or client-side." Otherwise it would mean, that there
>>> are programming languages that couldn't be used outside of a
>>> client-server context.
>>
>> Exactly *this* is the wrong assumption, what "normally" means in this
>> context. It does *NOT* mean that a language can *never* be used in other
>> ways - it only says that is the the most common use of it.
>
> I thought there is the same difference between
>
> "No programming language is normally either server-side or
> client-side."
>
> and
>
> "No programming language is either normally server-side
> or normally client-side."
>
> as it is in German. Apparently, I was mistaken.
>
No, they do mean the same thing. But your interpretation is incorrect.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
|
|
|
|
| cr [message #183567 is a reply to message #183505] |
Fri, 01 November 2013 03:21 |
Richard Damon
Messages: 58
Registered: August 2011
Karma: 0
|
Member |
|
|
On 10/29/13, 7:18 AM, Thomas 'PointedEars' Lahn wrote:
> Richard Damon wrote:
>
>> On 10/28/13, 9:34 AM, Thomas 'PointedEars' Lahn wrote:
>>> Richard Damon wrote:
>>>> On 10/27/13, 10:22 PM, Thomas 'PointedEars' Lahn wrote:
>>>> > Richard Damon wrote:
>>>> >> […] The one thing that is fairly certain is that the
>>>> >> player will almost certainly NOT be written in PHP,
>>>> >
>>>> > That much is true.
>>>> >
>>>> >> as PHP is normally a server side language, and few clients will
>>>> >> understand it.
>>>> >
>>>> > A common misconception. *No* programming language is “normally” either
>>>> > “server-side” or “client-side”.
>>>>
>>>> Clearly a falsehood.
>>>
>>> [superseded]
>>>
>>>> I would expect that at least 95% of PHP executions
>>>> are done via mod-php or php-cgi in response to a http request, [tl;dr]
>>>
>>> So even by your standards there are 5% left for “client-side”
>>> applications.
>>
>> I consider 95% to be a reasonable definition for "normally". I will add
>> that I normally ignore what you say because normally you are just
>> spouting gibberish (as it seems here).
>
> Why do you reply to the canceled posting?
>
I suppose this shows your level of understanding of Usenet and the
applicability of RFCs. Cancel messages are purely advisory, and
routinely ignored by the backbone because they are not authenticated. It
has been decades since one could expect a cancel to work.
> Your logic is flawed. “normally” is a weasel word. Much like with other
> programming languages, there are applications of PHP that have nothing to do
> with the client-server architecture. Apparently you do not know them. Rest
> assured that your numbers are from *thin air*. OTOH, I did not expect a
> reasonable, well-founded argument to begin with “Clearly”, as pointed out in
> the posting that superseded the one you replied to.
Note, that your superseded message was injected to your server on
USENET, it appears, just 2 minutes before I replied. Due to the
transmission method of USENET, it is quite likely that your superseding
message hadn't reached the server that I read through before I posted,
and it is almost certain that I started my reply before you posted it.
You are snipping the expansion that showed why your statement is off
base. Making the statement that "No programming language is ..." says
that out of every programming language in existence, the count of
language with the following property MUST be zero. Finding even 1
counter example shows the statement false, and the ease of finding these
justifies "clearly".
"Normally", at least in the context it was used is not a "Weasel word".
Yes, it establishes that one is not claiming categorically 100% of the
time a property, just for the vast majority of the cases. For example,
if I state that I normally take the bus to work, this is still true if
about once a month I need to drive for some reason. But on the other
hand, if I actually drive 80% of the time, it would be false to say that
I normally take the bus.
As to being "Out of thin air", I will admit that I have no hard figures
on the actual ratio of usage, but I will stand on my experience that a
19:1 ratio of "Server" usage to CLI usage is very conservative, making
the label of PHP as being a "normally server side language" appropriate.
Similarly for EMCAScript, its usage on the client side so outweighs it
usage in other ways that it is normally a client side language.
>
>>> Please do not quote signatures.
>>
>> I don't, my reader automatically removes signatures from quotes, of
>> course if you put something before the signature delimiter, it ISN'T a
>> signature. For someone who likes to spout about what standards say, it
>> would make sense that you would follow them.
>
> There is no standard about it; there is a recommendation (RFC 1855). Like
> several other people on Usenet, I choose to interpret it differently, and to
> write my signature above the signature delimiter when I have something else
> in my (randomly chosen) .sig that exceeds the recommended limit of four
> lines.
So, rules you don't like can be "reinterpreted"? The documents do
clearly state that the customary "-- " line separates what is to be
considered the "body" of the message from what is to be considered the
signature, which best practices indicates are to be stripped from
replies. The intentional moving of your name to the body would be
normally seen as a sign that you intend it to be part of the message,
and not part of the signature to be automatically stripped.
You also seem to admit that you don't care if you regularly violate the
accepted netiquette, i.e., you really don't care about other people.
>
> So you need your newsreader to think for you?
>
Nope, but I do let it do what computers do well, the routine tasks, like
trimming signatures and adjusting messages to meet the RFC line length
guidelines.
> Score adjusted
>
> PointedEars
>
|
|
|
|
| Re: server-side vs.client-side [message #183584 is a reply to message #183556] |
Fri, 01 November 2013 16:53 |
Michael Vilain
Messages: 88
Registered: September 2010
Karma: 0
|
Member |
|
|
In article <52721771(dot)6090201(at)arnowelzel(dot)de>,
Arno Welzel <usenet(at)arnowelzel(dot)de> wrote:
> Christoph Michael Becker, 2013-10-30 20:54:
>
>> Jerry Stuckle wrote:
>>
>>> One question - since both you and Thomas seem to be from Germany, and
>>> have the same misunderstanding of the word "normally", what does
>>> "normally" translate to in German? What does it mean?
>>
>> In Germany it is "normalerweise"/"blicherweise", what means as much
>> usually. Anyway, a misunderstanding of the term "normally" is not the
>> problem here for me. In my opinion, it is correct to state: "PHP is
>> normally (usually, most often etc.) used on a server (for server-side
>> programming)."
>>
>> It is as well correct to state: "No programming language is normally
>> either server-side or client-side." Otherwise it would mean, that there
>> are programming languages that couldn't be used outside of a
>> client-server context.
>
> Exactly *this* is the wrong assumption, what "normally" means in this
> context. It does *NOT* mean that a language can *never* be used in other
> ways - it only says that is the the most common use of it.
I've never seen javascript run on anything but a browser. Unless
someone's developed a non-browser version, I personally consider it a
client-side scripting language. It's meant to control a browser and
nothing else, which is the client for web pages.
php is not intended to run on the browser. It runs on the server that
the browser talks to. It can run as part of the web-server or from the
command line. Same for perl, Java, python, ruby, or C. To me, that
makes them server-side programming languages.
I don't know if that matches other's definitions of server-side vs.
client-side, but that's my definition.
--
DeeDee, don't press that button! DeeDee! NO! Dee...
[I filter all Goggle Groups posts, so any reply may be automatically ignored]
|
|
|
|
Calendar
Search
Help
Members
Register
Login
Home
]