Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #11595 > unrolled thread

checking for audio playing ???

Back to article view | Back to comp.lang.php

Contents

  checking for audio playing ??? richard <noreply@example.com> - 2013-10-27 10:58 -0400
    Re: checking for audio playing ??? Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-27 16:45 +0100
      Re: checking for audio playing ??? richard <noreply@example.com> - 2013-10-27 12:01 -0400
    Re: checking for audio playing ??? Denis McMahon <denismfmcmahon@gmail.com> - 2013-10-27 17:53 +0000
      Re: checking for audio playing ??? richard <noreply@example.com> - 2013-10-27 14:24 -0400
        Re: checking for audio playing ??? Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-10-27 18:38 +0000
        Re: checking for audio playing ??? Richard Damon <Richard@Damon-Family.org> - 2013-10-27 14:43 -0400
          Re: checking for audio playing ??? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-28 03:22 +0100
            Re: checking for audio playing ??? Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-28 05:49 -0400
            Re: checking for audio playing ??? Richard Damon <Richard@Damon-Family.org> - 2013-10-28 08:11 -0400
              Re: checking for audio playing ??? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-28 14:37 +0100
              Re: checking for audio playing ??? "Beauregard T. Shagnasty" <a.nony.mous@example.invalid> - 2013-10-28 13:49 +0000
              Re: checking for audio playing ??? Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-28 10:01 -0400
              Re: checking for audio playing ??? Scott Johnson <noonehome@chalupasworld.com> - 2013-10-28 11:36 -0700
              Re: checking for audio playing ??? Richard Damon <Richard@Damon-Family.org> - 2013-10-28 21:29 -0400
                Re: checking for audio playing ??? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-10-29 12:18 +0100
                  cr Richard Damon <Richard@Damon-Family.org> - 2013-10-31 23:21 -0400
                    Re: cr Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-03 15:29 +0100
                      Re: cr Jerry Stuckle <jstucklex@attglobal.net> - 2013-11-03 09:34 -0500
                      Re: cr Richard Damon <Richard@Damon-Family.org> - 2013-11-03 15:18 -0500
              Re: checking for audio playing ??? Arno Welzel <usenet@arnowelzel.de> - 2013-10-29 20:12 +0100
                Re: checking for audio playing ??? Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-10-29 20:21 +0000
            Re: checking for audio playing ??? Arno Welzel <usenet@arnowelzel.de> - 2013-10-29 20:10 +0100
              server-side vs.client-side (was: checking for audio playing ???) Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-29 21:45 +0100
                Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-29 20:54 -0400
                  Re: server-side vs.client-side Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-30 03:18 +0100
                    Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-29 22:31 -0400
                    Re: server-side vs.client-side Arno Welzel <usenet@arnowelzel.de> - 2013-10-30 09:20 +0100
                      Re: server-side vs.client-side Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-30 19:04 +0100
                        Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-30 14:58 -0400
                          Re: server-side vs.client-side Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-30 20:54 +0100
                            Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-30 16:21 -0400
                              Re: server-side vs.client-side Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-30 21:55 +0100
                                Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-30 17:07 -0400
                            Re: server-side vs.client-side Arno Welzel <usenet@arnowelzel.de> - 2013-10-31 09:40 +0100
                              Re: server-side vs.client-side Christoph Michael Becker <cmbecker69@arcor.de> - 2013-10-31 23:03 +0100
                                Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-10-31 20:38 -0400
                                Re: server-side vs.client-side Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-02 17:57 +0100
                                  Re: server-side vs.client-side Arno Welzel <usenet@arnowelzel.de> - 2013-11-02 19:36 +0100
                                    Re: server-side vs.client-side The Natural Philosopher <tnp@invalid.invalid> - 2013-11-02 18:44 +0000
                                    Re: server-side vs.client-side Denis McMahon <denismfmcmahon@gmail.com> - 2013-11-03 00:28 +0000
                                  Re: server-side vs.client-side Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-11-02 19:01 +0000
                                  Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-11-02 21:40 -0400
                              Re: server-side vs.client-side Michael Vilain <vilain@NOspamcop.net> - 2013-11-01 09:53 -0700
                                Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-11-01 13:53 -0400
                                  Re: server-side vs.client-side Tim Streater <timstreater@greenbee.net> - 2013-11-01 21:10 +0000
                                    Re: server-side vs.client-side The Natural Philosopher <tnp@invalid.invalid> - 2013-11-01 22:25 +0000
                                      Re: server-side vs.client-side Tim Streater <timstreater@greenbee.net> - 2013-11-01 22:29 +0000
                                      Re: server-side vs.client-side Jerry Stuckle <jstucklex@attglobal.net> - 2013-11-01 20:37 -0400
                                    Re: server-side vs.client-side Arno Welzel <usenet@arnowelzel.de> - 2013-11-02 01:26 +0100
                                Re: server-side vs.client-side The Natural Philosopher <tnp@invalid.invalid> - 2013-11-01 18:37 +0000
                                Re: server-side vs.client-side Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2013-11-01 19:19 +0000
                                Re: server-side vs.client-side Arno Welzel <usenet@arnowelzel.de> - 2013-11-02 01:24 +0100
                                Re: server-side vs.client-side Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-02 17:46 +0100
                                  Re: server-side vs.client-side Richard Damon <Richard@Damon-Family.org> - 2013-11-02 15:41 -0400
                                    Re: server-side vs.client-side Tim Streater <timstreater@greenbee.net> - 2013-11-02 21:37 +0000
                                    Re: server-side vs.client-side Arno Welzel <usenet@arnowelzel.de> - 2013-11-03 10:48 +0100
                                      Re: server-side vs.client-side Tim Streater <timstreater@greenbee.net> - 2013-11-03 10:28 +0000
                                        Re: server-side vs.client-side Arno Welzel <usenet@arnowelzel.de> - 2013-11-05 11:15 +0100
                                          Re: server-side vs.client-side Tim Streater <timstreater@greenbee.net> - 2013-11-05 12:47 +0000
                                    Re: server-side vs.client-side Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2013-11-03 14:16 +0100
                                      Re: server-side vs.client-side Tim Streater <timstreater@greenbee.net> - 2013-11-03 16:00 +0000
                                        Re: server-side vs.client-side Chuck Anderson <cycletourist@invalid.invalid> - 2013-11-03 14:52 -0700
                                          Re: server-side vs.client-side Chuck Anderson <cycletourist@invalid.invalid> - 2013-11-03 23:19 -0700
                                            Re: server-side vs.client-side Tim Streater <timstreater@greenbee.net> - 2013-11-04 18:02 +0000
                Re: server-side vs.client-side Arno Welzel <usenet@arnowelzel.de> - 2013-10-30 09:09 +0100
        Re: checking for audio playing ??? Denis McMahon <denismfmcmahon@gmail.com> - 2013-10-28 15:23 +0000
          Re: checking for audio playing ??? The Natural Philosopher <tnp@invalid.invalid> - 2013-10-28 16:56 +0000
    Re: checking for audio playing ??? Doug Miller <doug_at_milmac_dot_com@example.com> - 2013-10-27 18:22 +0000
    Re: checking for audio playing ??? Arno Welzel <usenet@arnowelzel.de> - 2013-10-28 20:02 +0100

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#11716 — Re: server-side vs.client-side

On Sat, 02 Nov 2013 19:36:07 +0100, Arno Welzel wrote:

> We all know that PHP can be used in different ways and not just "server
> side". But when saying "PHP is normally used server side" this does not
> say anything at all about where PHP *can* be used, just what it is
> *meant* to be used for and what its strengths are. Just think a moment
> about the history of PHP - it all started as a set of tools to create
> HTML documents on the server:

s/*meant* to be/(usually|commonly|normally)/

I don't think php is meant to be used for anything, per se, as in there's 
no god given order that "thou shalt use php to do x".

But php was originally designed as a scripting language to sit behind a 
web server and dynamically create html content. It has since morphed into 
many other things, and it has many other uses, but I imagine that the 
majority of php code that is executed on a daily basis is sitting behind 
a web server generating (x)html pages and / or other content intended to 
be accessed by means of a web browser and / or otherwise processing http 
requests.

Let's assume that globally, on all computers that have some form of php 
interpreter, a total of 3.5 * 10^13 php code statements are executed. 
This is a manufactured figure, a guesstimate, if you have a better figure 
for the number of php statements executed daily on a global basis, I'd 
love to hear it, and how you arrived at it.[1]

Now, what proportion of that php code do you think is involved in 
responding in some way to an http request, and what proportion of that php 
code do you think is not involved in responding in some way to an http 
request? Because I would guess that upwards of 90% of those 3.5 * 10^13 
lines of php is involved in responding to an http request, and I would 
happily state that I would consider that if over 90% of the php that 
executes globally on a daily basis is executing in response to http 
requests, then php is normally executed in a server environment in 
response to an http request.

[1] That's the equivalent of 3.5 billion people (50% of the global 
population) making 100 requests each, and each request causing 100 php 
code statements to be executed.

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#11710 — Re: server-side vs.client-side

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote in 
news:1543268.nVc8Rr6bpH@PointedEars.de:

> You are not.  “normally” is (used here as) a “weasel word”, and the argument 
> is fundamentally flawed.  What is “normally” – who defines what that is (not 
> what it means)?  At which percentage does “normally” start?  You can see 
> that this cannot lead to a sound argument.  Which is why I intentionally 
> double-quoted the word.

And this is why I keep saying you don't understand English nearly as well as you think you 
do; this is the charitable assumption, the alternative being that you're just an asshole.

"Normally" means "usually", "typically", "commonly" -- native speakers of English 
understand it to mean "the majority of the time". That one cannot assign an exact, specific 
percentage at which "sometimes" changes to "normally" does not render the concept of 
"normally" meaningless, your delusions to the contrary notwithstanding.

The *fact* is that PHP is *normally* (usually, typically, commonly) a language which is 
executed server-side -- and this fact is not altered by your inability to grasp it, whether that 
inability stems from the deficiencies in your grasp of the English language, or your innate 
insufferable pendantry.

[toc] | [prev] | [next] | [standalone]

#11717 — Re: server-side vs.client-side

On 11/2/2013 12:57 PM, Thomas 'PointedEars' Lahn wrote:
> 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.
>
> You are not.  “normally” is (used here as) a “weasel word”, and the argument
> is fundamentally flawe d.  What is “normally” – who defines what that is (not
> what it means)?  At which percentage does “normally” start?  You can see
> that this cannot lead to a sound argument.  Which is why I intentionally
> double-quoted the word.
>

There's only one weasel here - and it is NOT "normally".

>
> PointedEars
>

You really shouldn't criticize a language you don't understand, Pointed 
Head.


-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#11686 — Re: server-side vs.client-side

In article <52721771.6090201@arnowelzel.de>,
 Arno Welzel <usenet@arnowelzel.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]

[toc] | [prev] | [next] | [standalone]

#11689 — Re: server-side vs.client-side

On 11/1/2013 12:53 PM, Michael Vilain wrote:
> In article <52721771.6090201@arnowelzel.de>,
>   Arno Welzel <usenet@arnowelzel.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.
>

Michael,

While I agree with your definitions, I should point out there are other 
uses for PHP than server-side scripting.  I prefer PHP to bash for 
complicated CLI projects, for instance.  And there is a package (I don't 
remember the name) which allows javascript to run on the server, 
although I've never seen anyone actually using it.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#11693 — Re: server-side vs.client-side

In article <l50ppv$qdo$1@dont-email.me>, Jerry Stuckle
<jstucklex@attglobal.net> wrote:

> I prefer PHP to bash for complicated CLI projects, for instance.

I prefer PHP to *any* shell for any scripting purpose. Life's
complicated enough without arcane syntax. Look, if I'd wanted to learn
TECO, I'd have learnt it, OK?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#11695 — Re: server-side vs.client-side

On 01/11/13 21:10, Tim Streater wrote:
> In article <l50ppv$qdo$1@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
>
>> I prefer PHP to bash for complicated CLI projects, for instance.
>
> I prefer PHP to *any* shell for any scripting purpose. Life's
> complicated enough without arcane syntax. Look, if I'd wanted to learn
> TECO, I'd have learnt it, OK?
>
after years if writing C, I simply reach for the compiler if  a three 
line shell wont do it..
If there was the same library support in C and the ability to dump text 
straight, I wouldn't use PHP at all.


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

[toc] | [prev] | [next] | [standalone]

#11696 — Re: server-side vs.client-side

In article <l519pl$lpt$1@news.albasani.net>, The Natural Philosopher
<tnp@invalid.invalid> wrote:

> On 01/11/13 21:10, Tim Streater wrote:
> > In article <l50ppv$qdo$1@dont-email.me>, Jerry Stuckle
> > <jstucklex@attglobal.net> wrote:
> >
> >> I prefer PHP to bash for complicated CLI projects, for instance.
> >
> > I prefer PHP to *any* shell for any scripting purpose. Life's
> > complicated enough without arcane syntax. Look, if I'd wanted to learn
> > TECO, I'd have learnt it, OK?
> >
> after years if writing C, I simply reach for the compiler if  a three 
> line shell wont do it..
> If there was the same library support in C and the ability to dump text 
> straight, I wouldn't use PHP at all.

Mmm, well its nearly 25 years since I used C in anger, and these days I
can't be arsed to worry about types and the lack of string handling in
C. Let the giant brain do it, is what I say. I just get on and write
code.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#11699 — Re: server-side vs.client-side

On 11/1/2013 6:25 PM, The Natural Philosopher wrote:
> On 01/11/13 21:10, Tim Streater wrote:
>> In article <l50ppv$qdo$1@dont-email.me>, Jerry Stuckle
>> <jstucklex@attglobal.net> wrote:
>>
>>> I prefer PHP to bash for complicated CLI projects, for instance.
>>
>> I prefer PHP to *any* shell for any scripting purpose. Life's
>> complicated enough without arcane syntax. Look, if I'd wanted to learn
>> TECO, I'd have learnt it, OK?
>>
> after years if writing C, I simply reach for the compiler if  a three
> line shell wont do it..
> If there was the same library support in C and the ability to dump text
> straight, I wouldn't use PHP at all.
>
>

Yeah, when all you've got is a hammer, every problem is a nail.

Intelligent programmers use the most appropriate tool.  I do use C and 
C++, but not for basic scripts.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#11698 — Re: server-side vs.client-side

Tim Streater, 2013-11-01 22:10:

> In article <l50ppv$qdo$1@dont-email.me>, Jerry Stuckle
> <jstucklex@attglobal.net> wrote:
> 
>> I prefer PHP to bash for complicated CLI projects, for instance.
> 
> I prefer PHP to *any* shell for any scripting purpose. Life's
> complicated enough without arcane syntax. Look, if I'd wanted to learn
> TECO, I'd have learnt it, OK?

I prefer bash for shell scripting - the syntax is not far from C or PHP
and you have the big advantage, that you don't need a PHP runtime set up.

And things like "do something with every file named like x in path y" is
really no fun in PHP.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#11690 — Re: server-side vs.client-side

On 01/11/13 16:53, Michael Vilain wrote:
> In article <52721771.6090201@arnowelzel.de>, Arno Welzel
> <usenet@arnowelzel.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.
>


Java is the one I've seen employed both sides almost equally,otherwise
what you say is broadly true. If we are talking browsers.

If we are talking generic custom client server apps, there are no real 
restrictions on what you wrote either end in, beyond the ability of the 
platform to support the code.




> I don't know if that matches other's definitions of server-side vs.
> client-side, but that's my definition.
>


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

[toc] | [prev] | [next] | [standalone]

#11692 — Re: server-side vs.client-side

On Fri, 01 Nov 2013 17:53:28 Michael Vilain wrote:
> I've never seen javascript run on anything but a browser.

I do run javascript on the server within one of my web applications.
I don't like it, but the reason is that a certain XML-standard
allowes formulas to be specified ("javascript is used as the formula
language; the return value must be boolean"). So I use a wrapper
calling smjs to parse and execute this.

(Nevertheless I think that the term "client-side scripting language"
fits quite well. Other use-cases are rather exotic)

Bye,
  Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Freude mit Stefan, lüstern und traumhaft!
(Sloganizer)

[toc] | [prev] | [next] | [standalone]

#11697 — Re: server-side vs.client-side

Michael Vilain, 2013-11-01 17:53:

> In article <52721771.6090201@arnowelzel.de>,
>  Arno Welzel <usenet@arnowelzel.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.

JFTR: see Node.js - this is "server side" JavaScript:

<http://nodejs.org/about/>

But generally you're right - the more common use of JavaScript is
"client side" and originally JavaScript has been created just for this
purpose, even though ECMAScript is not limited to this and can virtually
be found anywhere (even as scripting language for Office applications or
for command line tools).

Therefore I would also not call JavaScript a "normally server side
language" - using it on a server is just another option.

> 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 even don't know any PHP runtime for browsers.

> I don't know if that matches other's definitions of server-side vs. 
> client-side, but that's my definition.

I would define "server side" in the context of PHP as "will usually not
be executed by a user agent". If the "server" is a public web server or
just the box sitting under your desktop does not make a big difference.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#11705 — Re: server-side vs.client-side

Michael Vilain wrote:

> Arno Welzel <usenet@arnowelzel.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.

Which does not mean anything.  Not only is that an /argumentum ad 
ignorantiam/, a classic fallacy; but also, contrary to common misconception, 
there is not even a (single) programming language called “javascript”.

> Unless someone's developed a non-browser version, I personally consider it
> a client-side scripting language.

“javascript” is not even a scripting language, let alone a programming 
language.  There is no “javascript”.

> It's meant to control a browser and nothing else,

ECMAScript implementations, which you might mistakenly subsume under 
“javascript”, are scripting languages.  (So is PHP.)  “A scripting language 
is a programming language that is used to manipulate, customise, and 
automate the facilities of an existing system.”  (ECMAScript Language 
Specification, 5.1 Edition, section 4)  Nothing more, nothing less.

While the original purpose for JavaScript (first called Mocha, then 
LiveScript) was to provide scripting capabilities in the Netscape browser, 
it has surpassed those constraints already in the days of Netscape (see 
JavaScript 1.4 on Netscape Enterprise Server and successors).  Today (that 
is, since 2001 at the latest, 12 years ago), Netscape as a browser vendor 
does not exist anymore; there is ECMAScript (first Edition: 1997) and 
implementations of it.  Implementations like “JavaScript” in Adobe Reader 
and Google V8 JavaScript for node.js (an application server), and 
“JavaScript” for MongoDb (an object-oriented DBMS).

See also <http://PointedEars.de/es-matrix> pp.

> which is the client for web pages.

There are no “web pages” either.  There are HTML/XHTML/XML/SVG/MathML etc. 
documents at best.  “Web pages” is used by the same wannabes who think the 
World Wide Web and the Internet are the same, and say “IP” instead of 
“IP(v4) address when in fact “IP” means “Internet _Protocol_”.  Blind people 
talking about colors.
 
> php is not intended to run on the browser.

That much is true.  The original meaning of PHP by Rasmus Lerdorf in 1994 
was *P*ersonal *H*ome *P*age (intended to maintain his); it now means (more 
appropriately) *P*HP *H*ypertext *P*reprocessor.  However, that does not 
preclude the possibility that PHP can run in the browser, client-side, or 
that a PHP program does not have anything to do with hypertext at all; it is 
just a programming language.  But that was not even meant here.

> It runs on the server that the browser talks to.

No, it usually runs on the server that the HTTP client of the browser talks 
to, as part of a HTTP server application.

> It can run as part of the web-server or from the command line.

If a program runs from the command line, it does not matter whether the 
computer system it runs on is called a “server” for it could be, and 
reasonably be called, a “client” at the same time.  Therefore, the logic 
leading to a programming language in which such a program is written being 
called a “server-side (programming) language” is fundamentally flawed.

> Same for perl, Java, python, ruby, or C.

Yes, AISB the same logic is fundamentally flawed with regard to (all?) other 
programming languages (certainly the ones mentioned here).  There are Perl 
scripts that have nothing to do with HTTP, and there are Perl-based 
applications like Bugzilla that have.  There are client-side Java-based 
applications like Eclipse, SweetHome3D, and TV-Browser, and there are 
server-side JavaServer Pages (JSP) based on Java which run on, for example, 
Apache Tomcat.  There are Python client programs like ketchup(1) and 
youtube-dl(1), and there are Python-based application servers like Zope, and 
Web-based CMSs running on it like Plone.  There are C programs that have 
never seen a httpd or a network in general, controlling filesystems or local 
storage devices, and there is, for example the collection of C programs 
named Apache that make up a Web server.

> To me, that makes them server-side programming languages.

Which shows that, due to lack of basic knowledge and experience, you have 
not understood the problem.  Hopefully it is clearer to you now.
 
> I don't know if that matches other's definitions of server-side vs.
> client-side, but that's my definition.

Laymen like you can make up any definition they want; that does not mean 
that it makes sense, applies in general, or is generally accepted by 
professionals (like me).


PointedEars 
-- 
When all you know is jQuery, every problem looks $(olvable).

[toc] | [prev] | [next] | [standalone]

#11711 — Re: server-side vs.client-side

On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
> Michael Vilain wrote:
>> I've never seen javascript run on anything but a browser.
> 
> Which does not mean anything.  Not only is that an /argumentum ad 
> ignorantiam/, a classic fallacy; but also, contrary to common misconception, 
> there is not even a (single) programming language called “javascript”.
> 
Several Fallacies here:

First, this is not "argumentum ad ignorantiam" because that fallacy is
the fallacy of assuming something is true because it has not been proven
false. You might be able to claim a fallicy of lack of evidence does not
imply evidence of the lack, but the problem with citing that is the
claim isn't that NO use of "javascipt" is not client-side, but that the
"norm" for "javascript" is client-side, which means that any possible
server-side use, if it exist, needs to be uncommon, which IS supported
(but maybe not proved) by a lack of observation. Refutation of this
observation could be done by showing a existing usage *of common enough
usage* to negate the "normally" tag.


There is a language called "javascript", even your beloved ECMAScipt.org
site admits this, stating in at least one location:

"ECMAScript" is the name under which the language more commonly known as
"JavaScript" is standardized.

Which admits to the existence of language with the name of "javascript",
it just isn't the name of the language that the standard applies to.

Your instance that "There is no javascript" is a denial of reality.

The rest of your rant is similarly filled with the flaw that something
must be wrong because it doesn't match YOUR particular unusual
definition (or lack there of) even if it matches the commonly use meaning.

[toc] | [prev] | [next] | [standalone]

#11713 — Re: server-side vs.client-side

In article <pAcdu.115847$sp1.45670@en-nntp-15.dc1.easynews.com>,
Richard Damon <Richard@Damon-Family.org> wrote:

> Your instance that "There is no javascript" is a denial of reality.

Richard,

What PointyHead is complaining about is the capitalisation (or lack of
it). For some reason he thinks it's important (nay, crucial) that we
all say (or rather, write) "JavaScript".

The net result is unprofessional behaviour on his part: to wit, being
rude to everyone who doesn't follow his norms.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#11721 — Re: server-side vs.client-side

Richard Damon, 2013-11-02 20:41:

> On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
>> Michael Vilain wrote:
>>> I've never seen javascript run on anything but a browser.
>>
>> Which does not mean anything.  Not only is that an /argumentum ad 
>> ignorantiam/, a classic fallacy; but also, contrary to common misconception, 
>> there is not even a (single) programming language called “javascript”.
>>
[...]
> There is a language called "javascript", even your beloved ECMAScipt.org
> site admits this, stating in at least one location:
> 
> "ECMAScript" is the name under which the language more commonly known as
> "JavaScript" is standardized.

You may not know PointedEars good enough yet - it was about the proper
spelling of "JavaScript" instead of "javascript" ;-)



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#11722 — Re: server-side vs.client-side

In article <52761BF2.2020202@arnowelzel.de>, Arno Welzel
<usenet@arnowelzel.de> wrote:

> Richard Damon, 2013-11-02 20:41:
> 
> > On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
> >> Michael Vilain wrote:
> >>> I've never seen javascript run on anything but a browser.
> >>
> >> Which does not mean anything.  Not only is that an /argumentum ad 
> >> ignorantiam/, a classic fallacy; but also, contrary to common
> >> misconception, 
> >> there is not even a (single) programming language called “javascript”.
> >>
> [...]
> > There is a language called "javascript", even your beloved ECMAScipt.org
> > site admits this, stating in at least one location:
> > 
> > "ECMAScript" is the name under which the language more commonly known as
> > "JavaScript" is standardized.
> 
> You may not know PointedEars good enough yet - it was about the proper
> spelling of "JavaScript" instead of "javascript" ;-)

There is no difference in spelling between "JavaScript" and
"javascript". It's a difference in capitalisation, something which is
not so important in English, as, AIUI, in German.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

#11732 — Re: server-side vs.client-side

Am 03.11.2013 11:28, schrieb Tim Streater:

> In article <52761BF2.2020202@arnowelzel.de>, Arno Welzel
> <usenet@arnowelzel.de> wrote:
> 
>> Richard Damon, 2013-11-02 20:41:
>>
>>> On 11/2/13, 12:46 PM, Thomas 'PointedEars' Lahn wrote:
>>>> Michael Vilain wrote:
>>>>> I've never seen javascript run on anything but a browser.
>>>>
>>>> Which does not mean anything.  Not only is that an /argumentum ad 
>>>> ignorantiam/, a classic fallacy; but also, contrary to common
>>>> misconception, 
>>>> there is not even a (single) programming language called “javascript”.
>>>>
>> [...]
>>> There is a language called "javascript", even your beloved ECMAScipt.org
>>> site admits this, stating in at least one location:
>>>
>>> "ECMAScript" is the name under which the language more commonly known as
>>> "JavaScript" is standardized.
>>
>> You may not know PointedEars good enough yet - it was about the proper
>> spelling of "JavaScript" instead of "javascript" ;-)
> 
> There is no difference in spelling between "JavaScript" and
> "javascript". It's a difference in capitalisation, something which is
> not so important in English, as, AIUI, in German.

Well - there is a difference: JavaScript is the official name but
"javascript" not. Of course anybody would clearly understand
"javascript" as well but PointedEars insists teaching people the proper
use of names and precise logic as he seems to be a big fan of Vulcan
philosophy and logic.

Cite from <http://pointedears.de/scripts/test/es-matrix/>:

"Learn to think clearly. Learn to distinguish: what is, and what seems
to be."
-- Surak

BTW: "Surak" is a fictional Vulcan philosopher in Star Trek.

I would prefer Kant and his intepretation of "sapere aude" - but maybe
this is not fancy enough for some people ;-)



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de

[toc] | [prev] | [next] | [standalone]

#11734 — Re: server-side vs.client-side

In article <5278C545.1070401@arnowelzel.de>, Arno Welzel
<usenet@arnowelzel.de> wrote:

> Am 03.11.2013 11:28, schrieb Tim Streater:

> > There is no difference in spelling between "JavaScript" and
> > "javascript". It's a difference in capitalisation, something which is
> > not so important in English, as, AIUI, in German.
> 
> Well - there is a difference: JavaScript is the official name but
> "javascript" not. Of course anybody would clearly understand
> "javascript" as well but PointedEars insists teaching people the proper
> use of names and precise logic as he seems to be a big fan of Vulcan
> philosophy and logic.
> 
> Cite from <http://pointedears.de/scripts/test/es-matrix/>:
> 
> "Learn to think clearly. Learn to distinguish: what is, and what seems
> to be."
> -- Surak

Perhaps PointyHead needs a spell on the Punishment Planet. My PP, BTW,
has a still largely molten surface.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.php

csiph-web