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 1 of 4  [1] 2 3 4  Next page →

#11595 — checking for audio playing ???

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.

[toc] | [next] | [standalone]

#11596

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

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

#11597

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

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

#11599

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@gmail.com

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

#11601

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.

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

#11602

richard <noreply@example.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."

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

#11603

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.

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

#11605

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@news.demon.co.uk> (2004)

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

#11606

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@attglobal.net
==================

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

#11607

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.

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

#11609

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

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

#11610

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

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

#11611

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@attglobal.net
==================

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

#11614

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

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

#11618

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
> 

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

#11620

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@94.75.214.39>

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

#11681 — cr

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
> 

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

#11724 — Re: cr

Richard Damon wrote:

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

It rather shows that you are trolling since you are at least vaguely aware 
how Cancel messages work, and what they mean, and not only reply regardless 
but also deny their significance.

> Cancel messages are purely advisory,

Cancel messages are control messages.  A news server may ignore them at own 
risk.  That does not make them “purely advisory”.

<http://tools.ietf.org/html/rfc5536#section-3.2.3> pp.

> and routinely ignored by the backbone

There is no “backbone”; Usenet is explicitly decentralized.  Each news 
server administrator can set their own rules regarding to which messages to 
accept from which peers, which to keep, and which to distribute to which 
peers.

> because they are not authenticated.

Some news servers now require Cancel messages to be authenticated before 
executed, that is, to match the lock-signature of the posting to be 
canceled; others (like the one I am using since about 10 years) do not.

> It has been decades since one could expect a cancel to work.

Utter nonsense.  That a Cancel message works was the general idea.  It was 
only after some people abused this feature that some servers decided to 
ignore cancels or require authentication.

The Internet draft for lock-signing messages, and cancel messages to match 
that signature, is a lot younger than that.  And it has expired even though 
it is implemented.

<http://wiki.killfile.org/projects/usenet/faqs/cancel/>
<https://en.wikipedia.org/wiki/Control_message>
<http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01>
<http://individual.net/faq.php#1.12>

So much for *your* “understanding of Usenet and the applicability of RFCs”.  
It is also exemplified by the way you changed the Subject header field 
value.

> Note, that your superseded message was injected to your server on
> USENET, it appears, just 2 minutes before I replied. […]

,----
| […]
| Message-ID: <1434655.Yjjdx3QzlV@PointedEars.de>
| From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
| […]
| Date: Mon, 28 Oct 2013 14:34:58 +0100
| […]
| References: <1ia1p6efkuy6j.ew455c20yr22$.dlg@40tude.net> 
<l4jjv1$16b$2@dont-email.me> <a4mqn9voa0zs$.2gqi5acsdw6l$.dlg@40tude.net> 
<P9dbu.14655$9X3.6324@en-nntp-03.dc1.easynews.com> 
<4129338.JVDsMHeclA@PointedEars.de> <Yvsbu.14426$Lj7.6142@en-
nntp-01.dc1.easynews.com>
| […]
`----

That was 2013-10-28 13:34:58 UTC.

,----
| Message-ID: <9415386.0xDGcqzFey@PointedEars.de>
| From: Thomas 'PointedEars' Lahn <PointedEars@web.de>
| […]
| Date: Mon, 28 Oct 2013 14:37:03 +0100
| […]
| Supersedes: <1434655.Yjjdx3QzlV@PointedEars.de>
`----

That was 2013-10-28 13:37:03 UTC (about 2 minutes later).  To be sure (not 
all servers support “Supersedes” either), I sent the corresponding Cancel 
message only seconds later.

,----
| […]
| From: Richard Damon <Richard@Damon-Family.org>
| […]
| References: <1ia1p6efkuy6j.ew455c20yr22$.dlg@40tude.net> 
<l4jjv1$16b$2@dont-email.me> <a4mqn9voa0zs$.2gqi5acsdw6l$.dlg@40tude.net> 
<P9dbu.14655$9X3.6324@en-nntp-03.dc1.easynews.com> 
<4129338.JVDsMHeclA@PointedEars.de> <Yvsbu.14426$Lj7.6142@en-
nntp-01.dc1.easynews.com> <1434655.Yjjdx3QzlV@PointedEars.de>
| In-Reply-To: <1434655.Yjjdx3QzlV@PointedEars.de>
| […]
| Message-ID: <wcEbu.10265$UA3.1277@en-nntp-08.dc1.easynews.com>
| […]
| Date: Mon, 28 Oct 2013 21:29:53 -0400
| […]
`----

That was 2013-10-29 01:29:53 UTC, more than 10 hours later.  I would pity 
you for your slow 20th century newsfeed if it were so.

I will now leave you to your further “misconceptions”, lest you do not waste 
more of my precious time.  May you die in ignorance.  *PLONK*

F'up2 poster

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

#11725 — Re: cr

On 11/3/2013 9:29 AM, Thomas 'PointedEars' Lahn wrote:

... an even bigger bunch of bull manure than normal.  Then he changes 
the FUP so no one can call him on his crap publicly.

Pointed Head, you have once again made a huge fool of yourself.  And 
you've only limited your chance of gaining any accurate information by 
plonking someone who was 100% correct in his statements.

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

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

#11727 — Re: cr

On 11/3/13, 9:29 AM, Thomas 'PointedEars' Lahn wrote:
> Richard Damon wrote:

> It rather shows that you are trolling since you are at least vaguely aware 
> how Cancel messages work, and what they mean, and not only reply regardless 
> but also deny their significance.
> 
>> Cancel messages are purely advisory,
> 
> Cancel messages are control messages.  A news server may ignore them at own 
> risk.  That does not make them “purely advisory”.
> 
> <http://tools.ietf.org/html/rfc5536#section-3.2.3> pp.


Note that RFC5537 which defines the cancel message, describes it as a
request, and that serving agents may elect to honor them or not. It is
NOT "ignore at your own risk"
> 
>> and routinely ignored by the backbone
> 
> There is no “backbone”; Usenet is explicitly decentralized.  Each news 
> server administrator can set their own rules regarding to which messages to 
> accept from which peers, which to keep, and which to distribute to which 
> peers.
> 

Having a backbone and being decentralized are NOT contradictory states.
There is a backbone of "Tier 1" servers that handle most of the "long
haul" connections. These then peer with Tier 2 servers, and down the
line. Better lower tier servers will connect with multiple upstream
peers for redundancy.

>> because they are not authenticated.
> 
> Some news servers now require Cancel messages to be authenticated before 
> executed, that is, to match the lock-signature of the posting to be 
> canceled; others (like the one I am using since about 10 years) do not.
> 
>> It has been decades since one could expect a cancel to work.
> 
> Utter nonsense.  That a Cancel message works was the general idea.  It was 
> only after some people abused this feature that some servers decided to 
> ignore cancels or require authentication.
> 
And this abuse happened decades ago, my experience is that cancels did
not work in the mid 90's (which is about 2 decades ago). My experience
is that MOST servers ignore cancels, as they have for decades.

> The Internet draft for lock-signing messages, and cancel messages to match 
> that signature, is a lot younger than that.  And it has expired even though 
> it is implemented.
> 
> <http://wiki.killfile.org/projects/usenet/faqs/cancel/>
> <https://en.wikipedia.org/wiki/Control_message>
> <http://tools.ietf.org/html/draft-ietf-usefor-cancel-lock-01>
> <http://individual.net/faq.php#1.12>
> 

An expired draft RFC does not establish rules to run the internet. The
fact that it IS an expired draft indicates that there were likely
problems in implementing it. There may be a few servers which implement
this, but that hardly makes it something to be counted on. Plus, since
your message didn't have the needed headers to begin with, this is
irrevelent.

> So much for *your* “understanding of Usenet and the applicability of RFCs”.  
> It is also exemplified by the way you changed the Subject header field 
> value.

That was purely accidental. A feline felt they were being ignore and
pushed some keys, as I was getting ready to send.

> F'up2 poster
Follow up ignored.
> 

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web