response for server every second

[apoorv....@gmail.com]

I want to get response from server every one second, the output will contain some value which I need to process in front end.

In backend I am using some queries to read data from mysql and return me output.

Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront

None of these work for me usually it is taking 3-4 seconds to get me response,

classic example to see this working(getting output in one sec)

http://madbid.com

Please let me know if anyone has some solution for this.

[Jerry Stuckle]

You're not going to be able to do it with PHP. The HTTP protocol is a
request/response protocol; the client makes a request and the server
responds. But there is no guarantee how long it will take for the
server to respond. It may be 0.1s or it may be 30s. Both are equally
valid.

You'll need to find some other means of doing it.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Erwin Moller]

Hi,

I have 2 observations:

1) How many clients are requesting that info on the server?
If you have multiple clients, think over your design (i'll come back to
that)
Let's look at XML HTTP Request (XHR) first (what you called AJAX):
What happens?
a) Client request a PHP page
b) Server much launch the process
c) PHP runs, and starts a database query
d) Database processes the query, and answers
e) PHP delivers the answer as output back to the requesting client
f) Client updates the screen

This is just not feasible every second.
Try that with 1000 clients. ;-)
There is so much overhead involved, and networking, you can't expect
this to run every second.

Solution:
Create a cronjob that runs every second.
Let it call your PHP script that queries the database.
Instead of responding to a client, let PHP put its output in a file in a
public directory.
Let XHR directly fetch this file.
This is much faster.

Warning: write the file as myOutput_tmp.xml, then rename to
myOutput.xml, otherwise you risk trying to read a file that is in the
process of being written.
I assume that your PHP script end within the second, otherwise you have
another problem. If, for example, your DB query takes 5 secs, the whole
adventure will fail, whatever you try.

Did you take timestamps for the whole PHP script (from start to end)?
If that is close to 1 second, you have to find another solution.

2) Use nodeJS
Indeed, no PHP. No AJAX.
NodeJS is extremely fast and supports sockets.
If you are a bit familiar with ECMA Script (such as Javascript), try
this route.

Good luck

Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens

[Jerry Stuckle]

> If that is close to 1 second, you have to find another solutionr
>

While yours are all good suggestions, it's still no guarantee, Erwin.
Even just retrieving a static page can take more than 1 second,
depending on server load, available bandwidth, client load and even
which browser is to parsing the HTML.

> 2) Use nodeJS
> Indeed, no PHP. No AJAX.
> NodeJS is extremely fast and supports sockets.
> If you are a bit familiar with ECMA Script (such as Javascript), try
> this route.
>

Another possibility. So is a Java applet, .NET and probably a dozen
other ways, all of which he can find better help on an appropriate
newsgroup.

> Good luck
>
> Regards,
> Erwin Moller
>



--

[Allodoxaphobia]

Of course, if this is all wholly on a _local_ network....


sigh...
The Internet Of Things is really going to raise the noise floor
on the interweb.....

[Jerry Stuckle]

The same applies to a local network. They can have slow response time,
also.

>
> sigh...
> The Internet Of Things is really going to raise the noise floor
> on the interweb.....
>

What is the "interweb"? There's the world wide web, and internet.

[Richard Yates]

Senator Ted Stevens said that it was all a "series of tubes."

Allodoxaphobia's use is similarly ridiculous, but in his case it is an
intentional, joking neologism.

[Jerry Stuckle]

Richard, I'm not sure it is a joke. I've seen some people who think
it's a real term. I just don't know any more.

[apoorv....@gmail.com]

Thanks for your answer Erwin If we use web sockets the whole point is that we don't have to make connection to the database every time can we use same with php and httprequest aka ajax and use a persistent connection so that we dont have to make the connection every time we query the database would that make things faster.

[Erwin Moller]

On 6/11/2015 9:14 AM, apoorv....@gmail.com wrote:
> On Wednesday, June 10, 2015 at 8:11:38 PM UTC+5:30, Erwin Moller wrote:

> Hello Erwin Thanks for your answer The whole point of web socket is that we dont have to make the connection to the database every time but if we use persistent connection with php and ajax would that make things faster.
>

I cannot follow you.
As I understand you want:
- A client that gets an update on something that could happen in the
database.
- This should happen every second.

So, do you need to query a database or not?
And yes, sockets are much faster than invoking a fresh HTTP request.

Good luck,

[apoorv....@gmail.com]

Yes buddy I want to query the database and I want it to happen fast so the user won't feel any latency.

It's more like a bidding platform when a user bid on a item that value is stored in database when he bids again that value is updated or new value is inserted in database with the same id and so on.

now imagine thousands of user logging in and bidding and there is a sort of timer that updates itself every time a user bids. The person who bid last when the timer expires will be declared winner of the bid.

[Erwin Moller]

OK buddy,
So you cannot use my first suggestion, because you have different
queries for all clients, right?

In that case you have the following needs:
Some sort of socket communication with a running process on the server.
You don't even have to store it in the database, you can keep the bids
in-process (in-memory) instead of loosing precious time on database
communication. In-process is bloody fast.

After each auction is done, you can optionally store that data in a
database for later examination/debugging/marketing.

In any case: go sockets. Avoid HXR (Ajax)
You will have a huge performance increase that way.

I advise NodeJS over Java Applets because there is less technical
involvement needed on the client-side. With Applets your visitor has to
keep Java up to date, and must possible allow certain permissions.
Many people don't get that (they let everybody on the internet these days!)
NodeJS is completely transparent for the user (but less robust/mature
than Java I must say). But I am sure NodeJS can do the job of an auction
just fine.

But you cannot reliable deliver an update each second. Networking over
the whole world just isn't reliable enough for that. ;-)

Good luck.

[apoorv....@gmail.com]

Thanks for valuable output and I think I will only need one query for all the user that will carry their id with them.

I am keeping nodejs as an absolute last option because I am not very familiar with it and I have a shared hosting which won't support nodejs.

Can I use html local storage I assume that will be faster and later I will store that in the database.

[Matthew Carter]

apoorv....@gmail.com writes:

> Thanks for valuable output and I think I will only need one query for
> all the user that will carry their id with them.
>
> I am keeping nodejs as an absolute last option because I am not very
> familiar with it and I have a shared hosting which won't support
> nodejs.
>
> Can I use html local storage I assume that will be faster and later I
> will store that in the database.

Your options are HTTP requests or sockets.

If your requirement is 1s on the dot, you can't do it with HTTP
requests, as there is no guarantee a web server will respond within 1
second of a request firing off.

A socket is much faster, as it's a persistent connection which can
receive events (there is still no 100% guarantee of a reply every 1
second, but you'll have more success adhering to this with sockets than
HTTP requests - less overhead and not polling or request/response
based).

You could do with fine with javascript and HTTP if, instead of a firm 1s
requirement, you just make chained requests/local updates (think -
instead of using a setInterval javascript call to poll the server on a
1000ms timeout, recursively call your javascript polling function as
part of the success condition).

Maybe that would look (to the user) like an update at the 1s mark, 3s
mark, 8s mark etc.

That's going to be the best you'll get with shared hosting imho.

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

[Denis McMahon]

On Thu, 11 Jun 2015 04:16:57 -0700, apoorv.kanungo wrote:

> now imagine thousands of user logging in and bidding and there is a sort
> of timer that updates itself every time a user bids. The person who bid
> last when the timer expires will be declared winner of the bid.

You can't do High Frequency Trading in across the web using javascript
clients. It's just not possible. You need dedicated platforms with
compiled code connected to the exchanges using very high speed networks.

The levels of performance you are looking for are going to be made in the
back end processing, which is going to need very careful design and
serious performance tuning and optimisations.

Those of us who do have the knowledge to design such systems (and I am
not one of them) probably expect to be paid a great deal of money to do
so. You're unlikely to get that free in a newsgroup.

If you want an ebay clone, you need to recruit the sort of programmers
and build the sort of infrastructure and codebase that ebay has.

--
Denis McMahon, denismf...@gmail.com

[apoorv....@gmail.com]

hello Erwin I hope you are doing well I am seriously considering your cron job option But I checked in the cpanel that cron job can only be set up for
minimum of one minute so how could I set that up for one minute thanks for your help so far.

[Jerry Stuckle]

If your hosting company won't allow you to run a cron job once a second
(most shared hosting companies won't due to the overhead), you won't be
able to get one second response times.

The more I think about it, I don't think you'll be able to reliably get
the response time you want on a shared server. You're going to be
taking a lot of resources, especially if you get more than a handful of
users on your system at one time.

If a one second response time is critical, you will probably need to go
with a virtual private system (VPS) or, more probably, a dedicated
server. Both require significantly more expertise as you will be
responsible for maintaining the operating system and system security as
well as your web site. And then if you want CPanel you'll have to spend
even more.

And then, as Denis says, you'll need a good programmer to do the back
end. There aren't that many around who are good at high performance
systems (although there are a lot who claim to be).

[Gordon Burditt]

> It's more like a bidding platform when a user bid on a item that
value is stored in database when he bids again that value is updated
or new value is inserted in database with the same id and so on.

> now imagine thousands of user logging in and bidding and there
is a sort of timer that updates itself every time a user bids. The
person who bid last when the timer expires will be declared winner
of the bid.

Is it practical to use a dedicated bid-server program rather than
a web server? The bid-server is hard-coded (if necessary, in
hand-optimized assembly language) to process exactly *ONE* query
URL, (maybe with some variable inputs) and gives out a 500 error
for anything else. (The rest of the site you put on a different
web server.) The program accesses no static files; these are hard-coded
into the executable. It's unclear whether this program needs a
database, or it can *BE* a database, keeping track of at least the
current high bids in shared memory.

Is it necessary for the bid-server to wait for the client to ask
for a response, or is it acceptable to just continue generating
responses one a second until the connection breaks?


I am reminded here of the little SMTP "server" I put up once that
accepted a connection, forked, read a line of input, output "550
Spam Not Welcome Here", and went back to read another line. On
EOF, close the socket and the child exits. It managed to throw
away hundreds of mail messages a second (on one SMTP connection -
some spammers have been caught sending over a million SPAMs in one
SMTP connection, all of them rejected).

This machine wasn't supposed to need mail at all, and we knew of
no MX records pointing at it, it attracted a lot of incoming mail
connections. It was supposed to be a minimum-configuration machine
for testing applications to be sure they were acceptably fast. It
turned out that some of the GUI-ish apps needed more memory to
outrun a snail.

[Erwin Moller]

On 6/12/2015 5:59 AM, Denis McMahon wrote:
> On Thu, 11 Jun 2015 04:16:57 -0700, apoorv.kanungo wrote:
>
>> now imagine thousands of user logging in and bidding and there is a sort
>> of timer that updates itself every time a user bids. The person who bid
>> last when the timer expires will be declared winner of the bid.
>
> You can't do High Frequency Trading in across the web using javascript
> clients. It's just not possible.

I don't want to downplay some excellent point in your post, but nodejs +
its built-in sockets makes an ideal solution for real time trading.

Client side isn't really the problem.
The server + network (response time) is the bottleneck.
Unless you don't know what you are doing (using some stupid framework
for example), I don't see how the client-side scripting will be the
bottleneck.

You can look at some impressive concurrency testing results here:
(Nodejs versus Apache/PHP)

http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

Nodejs performs very well under high load, keeping short response times.

Of course, if you add more requirements, nodejs might not be the ideal
solution, but it is fast.

Combine that with nodejs's included socket communication to clients, and
you have a pretty good environment for real time trading, I expect.

I don't have experience with database connectivity in nodejs yet, but it
supports Postgres, mysql, etc.
But everything in Nodejs is based on callback functions, so no blocking
occurs. (Same for disk IO, etc)

Well, let's just say I am pretty impressed by Nodejs. :-)

[Christoph M. Becker]

Erwin Moller wrote:

> You can look at some impressive concurrency testing results here:
> (Nodejs versus Apache/PHP)
>
> http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php

Comparing the speed of a truck and a sports car might not be reasonable.
So have a look at
<https://philsturgeon.uk/blog/2013/11/benchmarking-codswallop-nodejs-v-php/>.
:)

--
Christoph M. Becker

[Erwin Moller]

I never worked with reactphp, so I have to claim ignorance here.
Looking into it right now. They claim non-blocking IO.

Does that mean you have to re-write your script to accommodate to
reactphp to gain the performance boon?

Regard,

[Christoph M. Becker]

Erwin Moller wrote:

> On 6/15/2015 8:42 PM, Christoph M. Becker wrote:
>> Erwin Moller wrote:
>>
>>> You can look at some impressive concurrency testing results here:
>>> (Nodejs versus Apache/PHP)
>>>
>>> http://zgadzaj.com/benchmarking-nodejs-basic-performance-tests-against-apache-php
>>
>> Comparing the speed of a truck and a sports car might not be reasonable.
>> So have a look at
>> <https://philsturgeon.uk/blog/2013/11/benchmarking-codswallop-nodejs-v-php/>.
>>
>> :)
>

> I never worked with reactphp, [...]

Me neither. I just wanted to point out that there may be good
alternatives to Node.js with regard to performance.

--
Christoph M. Becker

[apoorv....@gmail.com]

Very good suggestion Gordon but I am struggling that how would I do such when I have to store value in the database and also retrieve them.

I am thinking that I would maintain a text file and store all values on them with fwrite and them at some point run a cron that will store them in the database.

another option I am thinking is json but all that encoding,decoding and parsing will affect the performance.

[Jerry Stuckle]

Why take an extra step of storing the data in a file? It's just more
complication and overhead. It will take the same amount of time to
store the data in the database, no matter how you do it.

[apoorv....@gmail.com]

I am thinking about overhead and latency when I enter then in the database right away.

I think it would be easier if I first enter them in the text file and later I would store them in the database.

[Peter H. Coffin]

On Sun, 21 Jun 2015 23:06:30 -0700 (PDT), apoorv....@gmail.com
wrote:

> I am thinking about overhead and latency when I enter then in the
> database right away.
>
> I think it would be easier if I first enter them in the text file and
> later I would store them in the database.

Why would it be easier? It's obviously an extra step, it's obviously
more code and therefore more code to have errors in it. And your text
file may conceivably get out of sync with your database somehow, and
then you've got a big mess to clean up. Far better to let the database
database do the work, maintain the official clock, and enforce full
transactions.

--
Remember, a 12'x12'x18" raised floor can hold over a thousand gallons of
blood before it starts to seep up through the cracks.
-- Roger Burton West in the Monastery

[Thomas 'PointedEars' Lahn]

Erwin Moller wrote:

> On 6/10/2015 3:59 PM, apoorv....@gmail.com wrote:
>> I want to get response from server every one second, the output will
>> contain some value which I need to process in front end.
>>
>> In backend I am using some queries to read data from mysql and return me
>> output.
>>
>> Things I have tried 1) Ajax 2) Webserver Events 3) Amazon Cloudfront
>>
>> None of these work for me usually it is taking 3-4 seconds to get me
>> response,
>>
>> classic example to see this working(getting output in one sec)
>>
>> http://madbid.com
>

> […]

> 1) How many clients are requesting that info on the server?
> If you have multiple clients, think over your design (i'll come back to
> that)

No. See below.

> Let's look at XML HTTP Request (XHR) first (what you called AJAX):
> What happens?
> a) Client request a PHP page

No, that is precisely what in most cases does _not_ happen with XHR.
Which is why it is fast as compared to traditional approaches.

> b) Server much launch the process
> c) PHP runs, and starts a database query
> d) Database processes the query, and answers
> e) PHP delivers the answer as output back to the requesting client
> f) Client updates the screen
>
> This is just not feasible every second.

Probably true. Which is why you do not do low-latency work this way.

ad a) You do not request an entire document, only the data;
the HTTP connection is still open from before;
ad b) the server does not need to launch the PHP process because that
is still running from before: use PHP via FastCGI, not as Apache
module;
ad c) the database query result is cached by the database server,
so that the need for subsequent queries is minimized;
ad d) the query is optimized so as to run fast, by using indexes
and so on.
ad e) PHP delivers only the data to the Web server, or *as* Web
*service*, which serves it to the Web client;
ad f) Client-side scripting uses the data from the response
to update only parts of the document.

> Try that with 1000 clients. ;-)

No problem. Web server software can run multiple instances of itself and
each instance can run multiple threads. It is merely a matter of hardware
performance. BTST where I am working.

> There is so much overhead involved, and networking, you can't expect
> this to run every second.

True. But see above.

> Solution:
> Create a cronjob that runs every second.
> Let it call your PHP script that queries the database.
> Instead of responding to a client, let PHP put its output in a file in a
> public directory.
> Let XHR directly fetch this file.
> This is much faster.

And the data written will be out of date, and there will be concurrency
problems, while this is heavy on the hardware. Do not do that unless you
want to wreck your harddisk (or memory, if you use in-memory storage) in
the long-term.

> Warning: write the file as myOutput_tmp.xml, then rename to
> myOutput.xml, otherwise you risk trying to read a file that is in the
> process of being written.

Even heavier on resources. How many copies do you suggest should be lying
around on the harddisk? This is an Incredibly Bad Idea[tm].

Also, XML is not a good format for database dumps as it has much overhead.
JSON or YAML leaner formats, in general better suited to the task. But not
in this case.

The idea behind this is a good one though if the database is not updated
every second. The idea is called caching. You would not do that in the
filesystem, though, at least not directly. Server-side sessions come to
mind.

> 2) Use nodeJS
> Indeed, no PHP. No AJAX.
> NodeJS is extremely fast and supports sockets.

So is and does PHP. You are comparing apples and oranges. PHP does not
have to run via a Web server like Apache; you can write a Web service in
PHP, much like a nodeJS application.

> If you are a bit familiar with ECMA Script (such as Javascript), try
> this route.

_ECMAScript_, _JavaScript_. JavaScript is an implementation of ECMAScript;
actually JavaScript *are* implementations of ECMAScript as there are several
implementations (but not all of them) that contain “JavaScript” in their
name. At the time of writing, Netscape/Mozilla JavaScript, Google V8
JavaScript (in Chromium and nodeJS, now in Opera too), and KDE JavaScript,
to name a few. But there is also Microsoft JScript and Opera ECMAScript (in
older versions).

However, it is not so much a matter of the programming language but of the
browser environment API (e.g. the DOM), although whatever ECMAScript
implementation the HTML user agent supports is now [HTML5] the standard
default client-side scripting language, and implicitly has been the quasi-
standard for years.

<http://PointedEars.de/es-matrix>

--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> However, it is not so much a matter of the programming language but of the
> browser environment API (e.g. the DOM), although whatever ECMAScript
> implementation the HTML user agent supports is now [HTML5] the standard
> default client-side scripting language, and implicitly has been the quasi-
> standard for years.
>
> <http://PointedEars.de/es-matrix>

You can strike out “browser” here because you can use an ECMAScript
implementation, or something that compiles to one, server-side, too,
nodeJS *aside*.

[Denis McMahon]

On Sun, 21 Jun 2015 23:06:30 -0700, apoorv.kanungo wrote:

> I am thinking about overhead and latency when I enter then in the
> database right away.

> I think it would be easier if I first enter them in the text file and
> later I would store them in the database.

Have you done timing tests to compare open for append, write, close on a
file vs open, insert, close a database connection?

--
Denis McMahon, denismf...@gmail.com

[Jerry Stuckle]

Denis,

You forgot locking and unlocking the file, as well as the time required
to later process the file and update the database.

Plus what happens when the database process has the file locked and the
file write process wants to run?

[Erwin Moller]

On 6/22/2015 6:37 PM, Thomas 'PointedEars' Lahn wrote:

> Erwin Moller wrote:
>
>
>> Solution:
>> Create a cronjob that runs every second.
>> Let it call your PHP script that queries the database.
>> Instead of responding to a client, let PHP put its output in a file in a
>> public directory.
>> Let XHR directly fetch this file.
>> This is much faster.
>
> And the data written will be out of date, and there will be concurrency
> problems, while this is heavy on the hardware. Do not do that unless you
> want to wreck your harddisk (or memory, if you use in-memory storage) in
> the long-term.

The data the client receives is *always* out of date, no matter what you
do. Apparently 1 second of staleness is acceptable to the OP.

My suggestion by using 1 file is not a bad idea.
--> But it assumes that all the clients need the same information. <--

eg a file containing the latest bids, like:
"red bike": $34,45
"broken I-pad2": $5,00
"Pointed Ears How to Write Better Code": $450,50
etc

It wasn't clear in the original post if each client receives the same
data, so I gave it as a (very fast) option to consider.
Very fast compared to requerying the database for each request.

>
>> Warning: write the file as myOutput_tmp.xml, then rename to
>> myOutput.xml, otherwise you risk trying to read a file that is in the
>> process of being written.
>
> Even heavier on resources. How many copies do you suggest should be lying
> around on the harddisk?

1 copy.
Do you actually understand what situation I described?

> This is an Incredibly Bad Idea[tm].

You are entitled to your own opinion.
(But please don't present it like a fact, that confuses people who read
this discussion and can read better than you did.)

>
> Also, XML is not a good format for database dumps as it has much overhead.
> JSON or YAML leaner formats, in general better suited to the task. But not
> in this case.

You have that right.

>
> The idea behind this is a good one though if the database is not updated
> every second. The idea is called caching. You would not do that in the
> filesystem, though, at least not directly. Server-side sessions come to
> mind.

Many roads lead to Rome.
My example used a file, because that is extremely easy to understand.

>
>> 2) Use nodeJS
>> Indeed, no PHP. No AJAX.
>> NodeJS is extremely fast and supports sockets.
>
> So is and does PHP. You are comparing apples and oranges. PHP does not
> have to run via a Web server like Apache; you can write a Web service in
> PHP, much like a nodeJS application.

I must claim ignorance here, since I only run PHP inside a full fledged
webserver.

>
>> If you are a bit familiar with ECMA Script (such as Javascript), try
>> this route.
>
> _ECMAScript_, _JavaScript_. JavaScript is an implementation of ECMAScript;
> actually JavaScript *are* implementations of ECMAScript as there are several
> implementations (but not all of them) that contain “JavaScript” in their
> name. At the time of writing, Netscape/Mozilla JavaScript, Google V8
> JavaScript (in Chromium and nodeJS, now in Opera too), and KDE JavaScript,
> to name a few. But there is also Microsoft JScript and Opera ECMAScript (in
> older versions).

Free advise: You might consider putting that in your sig.
That way you don't have to type it in every other post.
(Or give up your one-man crusade against
Idiots-Who-Refuse-To-Understand-The-Difference-Between-Javascript-JavaScript-JScript-ECMAScript,
like me.)

>
> However, it is not so much a matter of the programming language but of the
> browser environment API (e.g. the DOM), although whatever ECMAScript
> implementation the HTML user agent supports is now [HTML5] the standard
> default client-side scripting language, and implicitly has been the quasi-
> standard for years.

Correct.

>
> <http://PointedEars.de/es-matrix>

[Thomas 'PointedEars' Lahn]

Erwin Moller wrote:

> The data the client receives is *always* out of date, no matter what you
> do.

Wrong.

> […]

> My suggestion by using 1 file is not a bad idea.

Yes, it is. There are also limits as to how many processes can concurrently
*read* from a single file.

> --> But it assumes that all the clients need the same information. <--

It also assumes unlimited resources.

> […]

> It wasn't clear in the original post if each client receives the same
> data, so I gave it as a (very fast) option to consider.
> Very fast compared to requerying the database for each request.

Probably slower and more limited than server-side sessions in any case.

>>> Warning: write the file as myOutput_tmp.xml, then rename to
>>> myOutput.xml, otherwise you risk trying to read a file that is in the
>>> process of being written.
>> Even heavier on resources. How many copies do you suggest should be
>> lying around on the harddisk?
>
> 1 copy.
> Do you actually understand what situation I described?

It was not at all clear what you meant.

>> This is an Incredibly Bad Idea[tm].
>
> You are entitled to your own opinion.
> (But please don't present it like a fact, that confuses people who read
> this discussion and can read better than you did.)

You mean “*guess* better”. Only *now* *you* have introduced the condition
that all clients get the same data.

>> […] You would not do [caching] in the filesystem, though, at least not

>> directly. Server-side sessions come to mind.
>
> Many roads lead to Rome.
> My example used a file, because that is extremely easy to understand.

Bad examples are worse than no examples at all. Especially if the caveats
are not pointed out.

>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>> this route.
>> _ECMAScript_, _JavaScript_. JavaScript is an implementation of
>> ECMAScript; actually JavaScript *are* implementations of ECMAScript as
>> there are several implementations (but not all of them) that contain

>> “JavaScript” in their name. […]

>
> Free advise: You might consider putting that in your sig.

^c

Too long; a sig should not exceed 4 lines à 80 characters. Also, I would
have to remove “Zend Certified PHP Engineer” from it, thereby an important
hint that I am also qualified to make such statements as I did elsewhere in
my posting.

> That way you don't have to type it in every other post.
> (Or give up your one-man crusade against
> Idiots-Who-Refuse-To-Understand-The-Difference-Between-Javascript-
> JavaScript-JScript-ECMAScript, like me.)

You are arguing like an idiot, indeed.

At this point, let me remind you of <http://thecodelesscode.com/case/195>
which Hans-Georg Michna kindly posted in <news:comp.lang.javascript>, and
whose point you did not seem to get back then.

HTH

[Jerry Stuckle]

On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
> Erwin Moller wrote:
>
>> The data the client receives is *always* out of date, no matter what you
>> do.
>
> Wrong.
>

And why not? Stoopid Pointed Head response - says something is wrong
but too stoopid to explain why.

>> […]
>> My suggestion by using 1 file is not a bad idea.
>
> Yes, it is. There are also limits as to how many processes can concurrently
> *read* from a single file.
>

And how many is that, Pointed Head? Too many for a web server to handle?

>> --> But it assumes that all the clients need the same information. <--
>
> It also assumes unlimited resources.
>

And why should it require unlimited resources?

>> […]
>> It wasn't clear in the original post if each client receives the same
>> data, so I gave it as a (very fast) option to consider.
>> Very fast compared to requerying the database for each request.
>
> Probably slower and more limited than server-side sessions in any case.
>

Maybe, maybe not. It depends on a lot of factors which have not been
defined.

>>>> Warning: write the file as myOutput_tmp.xml, then rename to
>>>> myOutput.xml, otherwise you risk trying to read a file that is in the
>>>> process of being written.
>>> Even heavier on resources. How many copies do you suggest should be
>>> lying around on the harddisk?
>>
>> 1 copy.
>> Do you actually understand what situation I described?
>
> It was not at all clear what you meant.
>

It was to me - and I would guess any *knowledgeable* person in this
newsgroup.

>>> This is an Incredibly Bad Idea[tm].
>>
>> You are entitled to your own opinion.
>> (But please don't present it like a fact, that confuses people who read
>> this discussion and can read better than you did.)
>
> You mean “*guess* better”. Only *now* *you* have introduced the condition
> that all clients get the same data.
>

I would say more of an "informed opinion" (which you don't have) rather
than a "guess". One I happen to agree with.

>>> […] You would not do [caching] in the filesystem, though, at least not
>>> directly. Server-side sessions come to mind.
>>
>> Many roads lead to Rome.
>> My example used a file, because that is extremely easy to understand.
>
> Bad examples are worse than no examples at all. Especially if the caveats
> are not pointed out.
>

So why do you keep expounding on bad examples?

>>>> If you are a bit familiar with ECMA Script (such as Javascript), try
>>>> this route.
>>> _ECMAScript_, _JavaScript_. JavaScript is an implementation of
>>> ECMAScript; actually JavaScript *are* implementations of ECMAScript as
>>> there are several implementations (but not all of them) that contain
>>> “JavaScript” in their name. […]
>>
>> Free advise: You might consider putting that in your sig.
> ^c
>
> Too long; a sig should not exceed 4 lines à 80 characters. Also, I would
> have to remove “Zend Certified PHP Engineer” from it, thereby an important
> hint that I am also qualified to make such statements as I did elsewhere in
> my posting.
>

More nonsense from the pedantic troll. This is not your personal newsgroup.

>> That way you don't have to type it in every other post.
>> (Or give up your one-man crusade against
>> Idiots-Who-Refuse-To-Understand-The-Difference-Between-Javascript-
>> JavaScript-JScript-ECMAScript, like me.)
>
> You are arguing like an idiot, indeed.
>

Pot - Kettle - Black.

> At this point, let me remind you of <http://thecodelesscode.com/case/195>
> which Hans-Georg Michna kindly posted in <news:comp.lang.javascript>, and
> whose point you did not seem to get back then.
>
> HTH
>

Which has absolutely nothing to do with this discussion - other than
something a troll would bring up. But then it's what I would expect of you.

[Thomas 'PointedEars' Lahn]

Jerry Stuckle wrote:

> On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
>> Erwin Moller wrote:
>>> The data the client receives is *always* out of date, no matter what you
>>> do.
>> Wrong.
>
> And why not?

You mean “why (is it wrong)?”? Because there is the possibility that the
data in the database has not changed when the response is received by the
client. (That was an easy one.)

>>> […]
>>> My suggestion by using 1 file is not a bad idea.
>> Yes, it is. There are also limits as to how many processes can
>> concurrently *read* from a single file.
>

> And how many is that, […]?

Depends.

> Too many for a web server to handle?

Impossible to say for sure. But better be safe than sorry.

>>> --> But it assumes that all the clients need the same information. <--
>> It also assumes unlimited resources.
>
> And why should it require unlimited resources?

Because, among others, the limit above has not been considered.

>>> […]
>>> It wasn't clear in the original post if each client receives the same
>>> data, so I gave it as a (very fast) option to consider.
>>> Very fast compared to requerying the database for each request.
>> Probably slower and more limited than server-side sessions in any case.
>
> Maybe, maybe not.

In which cases would server-side sessions be slower or only equally fast,
and more or only equally limited, than either of requerying the database or
direct file system access?

> It depends on a lot of factors which have not been defined.

I do not think so.

>>>> […] You would not do [caching] in the filesystem, though, at least not
>>>> directly. Server-side sessions come to mind.
>>> Many roads lead to Rome.
>>> My example used a file, because that is extremely easy to understand.
>> Bad examples are worse than no examples at all. Especially if the
>> caveats are not pointed out.
>
> So why do you keep expounding on bad examples?

I am pointing out that it is a bad example, and I am explaining why. If I
would not point it out and explain it, and nobody else would point it out
and explain it, the bad example could be taken as a good one. You would not
want that to happen, would you?

>> Too long; a sig should not exceed 4 lines à 80 characters. Also, I would
>> have to remove “Zend Certified PHP Engineer” from it, thereby an
>> important hint that I am also qualified to make such statements as I did
>> elsewhere in my posting.
>
> More nonsense from the pedantic troll. This is not your personal
> newsgroup.

As for Usenet signature recommendations, see

<https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>

and

<http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.

As for being a ZCE: We talk about that again that if and when you, too, have
become one of the only about 11'000 people world-wide in the ZCE Directory.
Based on the candidate IDs, I have calculated a success rate for all ZCE
exams of about 45 %; so there is a chance that you can pass, too.

[Jerry Stuckle]

On 6/23/2015 7:45 PM, Thomas 'Pointed Head' Lahn wrote:
> Jerry Stuckle wrote:
>
>> On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
>>> Erwin Moller wrote:
>>>> The data the client receives is *always* out of date, no matter what you
>>>> do.
>>> Wrong.
>>
>> And why not?
>
> You mean “why (is it wrong)?”? Because there is the possibility that the
> data in the database has not changed when the response is received by the
> client. (That was an easy one.)
>

In what way? Erwin's comment was "The data the client receives is
*always* out of date, no matter what you do." Explain your comment *in
that context*.

>>>> […]
>>>> My suggestion by using 1 file is not a bad idea.
>>> Yes, it is. There are also limits as to how many processes can
>>> concurrently *read* from a single file.
>>
>> And how many is that, […]?
>
> Depends.
>

Typical "I don't know - but I'm going to make a fool of myself and
criticize his idea anyway" comment.

If you can't define the limit, then you have no basis for your comment.

>> Too many for a web server to handle?
>
> Impossible to say for sure. But better be safe than sorry.
>

See above.

>>>> --> But it assumes that all the clients need the same information. <--
>>> It also assumes unlimited resources.
>>
>> And why should it require unlimited resources?
>
> Because, among others, the limit above has not been considered.
>

See above.

>>>> […]
>>>> It wasn't clear in the original post if each client receives the same
>>>> data, so I gave it as a (very fast) option to consider.
>>>> Very fast compared to requerying the database for each request.
>>> Probably slower and more limited than server-side sessions in any case.
>>
>> Maybe, maybe not.
>
> In which cases would server-side sessions be slower or only equally fast,
> and more or only equally limited, than either of requerying the database or
> direct file system access?
>

Maybe, maybe not. You made the comparison. Based on what?

>> It depends on a lot of factors which have not been defined.
>
> I do not think so.
>

More properly, your period should have come after "think".

>>>>> […] You would not do [caching] in the filesystem, though, at least not
>>>>> directly. Server-side sessions come to mind.
>>>> Many roads lead to Rome.
>>>> My example used a file, because that is extremely easy to understand.
>>> Bad examples are worse than no examples at all. Especially if the
>>> caveats are not pointed out.
>>
>> So why do you keep expounding on bad examples?
>
> I am pointing out that it is a bad example, and I am explaining why. If I
> would not point it out and explain it, and nobody else would point it out
> and explain it, the bad example could be taken as a good one. You would not
> want that to happen, would you?
>

No, you are not explaining why *anything* is a bad example. Only
claiming that bad examples are worse than none at all. Exactly what is
bad about it?

>>> Too long; a sig should not exceed 4 lines à 80 characters. Also, I would
>>> have to remove “Zend Certified PHP Engineer” from it, thereby an
>>> important hint that I am also qualified to make such statements as I did
>>> elsewhere in my posting.
>>
>> More nonsense from the pedantic troll. This is not your personal
>> newsgroup.
>
> As for Usenet signature recommendations, see
>
> <https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>
>
> and
>
> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.
>

And you're the only one on this newsgroup who gives a damn about it.
But then you're the only pedantic troll who thinks they own the group,
and everyone should follow your "rules"/

> As for being a ZCE: We talk about that again that if and when you, too, have
> become one of the only about 11'000 people world-wide in the ZCE Directory.
> Based on the candidate IDs, I have calculated a success rate for all ZCE
> exams of about 45 %; so there is a chance that you can pass, too.
>

Who cares? All the certification proves is that you can pass the exam.
Your posts here prove that passing an exam is no proof of being able to
do the work.

But then those who can't do the work depend on the exams and
certifications to prove their competence. Those of us who are competent
do not need such artificial props. We get plenty of work without them.

[apoorv....@gmail.com]

On Wednesday, June 24, 2015 at 5:51:50 AM UTC+5:30, Jerry Stuckle wrote:
> On 6/23/2015 7:45 PM, Thomas 'Pointed Head' Lahn wrote:
> > Jerry Stuckle wrote:
> >
> >> On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
> >>> Erwin Moller wrote:
> >>>> The data the client receives is *always* out of date, no matter what you
> >>>> do.
> >>> Wrong.
> >>
> >> And why not?
> >
> > You mean "why (is it wrong)?"? Because there is the possibility that the
> > data in the database has not changed when the response is received by the
> > client. (That was an easy one.)
> >
>
> In what way? Erwin's comment was "The data the client receives is
> *always* out of date, no matter what you do." Explain your comment *in
> that context*.
>

> >>>> [...]

> >>>> My suggestion by using 1 file is not a bad idea.
> >>> Yes, it is. There are also limits as to how many processes can
> >>> concurrently *read* from a single file.
> >>

> >> And how many is that, [...]?

> >
> > Depends.
> >
>
> Typical "I don't know - but I'm going to make a fool of myself and
> criticize his idea anyway" comment.
>
> If you can't define the limit, then you have no basis for your comment.
>
> >> Too many for a web server to handle?
> >
> > Impossible to say for sure. But better be safe than sorry.
> >
>
> See above.
>
> >>>> --> But it assumes that all the clients need the same information. <--
> >>> It also assumes unlimited resources.
> >>
> >> And why should it require unlimited resources?
> >
> > Because, among others, the limit above has not been considered.
> >
>
> See above.
>

> >>>> [...]

> >>>> It wasn't clear in the original post if each client receives the same
> >>>> data, so I gave it as a (very fast) option to consider.
> >>>> Very fast compared to requerying the database for each request.
> >>> Probably slower and more limited than server-side sessions in any case.
> >>
> >> Maybe, maybe not.
> >
> > In which cases would server-side sessions be slower or only equally fast,
> > and more or only equally limited, than either of requerying the database or
> > direct file system access?
> >
>
> Maybe, maybe not. You made the comparison. Based on what?
>
> >> It depends on a lot of factors which have not been defined.
> >
> > I do not think so.
> >
>
> More properly, your period should have come after "think".
>

> >>>>> [...] You would not do [caching] in the filesystem, though, at least not

Guys let's not fight I am sure all you guys are excellent developer and are generous to share your knowledge with rest of the world.

About My question I managed to get a prototype working using a json file right now I am testing with 10 user and I am facing some delay.

There are two parameters no of bids left and the timer no of bids is working fine but I am struggling with the timer.

About the delay I am fine with one second delay but to the user it should look like real time.

[Richard Heathfield]

On 24/06/15 00:10, Jerry Stuckle wrote:
> On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
>> Erwin Moller wrote:

<snip>

>>> Free advise: You might consider putting that in your sig.
>> ^c
>>
>> Too long; a sig should not exceed 4 lines à 80 characters. Also, I would
>> have to remove “Zend Certified PHP Engineer” from it, thereby an important
>> hint that I am also qualified to make such statements as I did elsewhere in
>> my posting.
>>
>
> More nonsense from the pedantic troll. This is not your personal newsgroup.

Neither is it /anyone's/ personal newsgroup, which is why we have
long-established conventions, known as "Netiquette", to help us to get
along better in email and on Usenet.

One of those conventions, which was codified twenty years ago and
already well-established before that, is that sig blocks should not
exceed four lines of sixty-five characters.

Another is: "Don't get involved in flame wars. Neither post nor respond
to incendiary material." (And here's me doing just that.)

There is an argument for allowing longer sig blocks nowadays, with
increased bandwidth availability and so on, but it's a lot harder to
justify constant bickering. Could I suggest that you folks try the
following every time you see something written by the other that you
disagree with: (1) try to write your reply as if the original article
had been written by a close and dear relative whom you don't wish to
offend, but whom needs putting right on a technical matter; (2) try to
find a way to end on a positive note. It might be less exciting for you,
but it will make much better reading in the archives. In the mirror of
history, flame wars *always* look bad.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[bill]

On 6/24/2015 2:34 AM, apoorv....@gmail.com wrote:
> About the delay I am fine with one second delay but to the user it should look like real time.

users are used to inexplicable delays in browser refreshing. If
this is used over the internet there will always be latency. If
you are running it over a LAN then you can strive for near-real-time.

bill

[Jerry Stuckle]

On 6/24/2015 4:52 AM, Richard Heathfield wrote:
> On 24/06/15 00:10, Jerry Stuckle wrote:
>> On 6/23/2015 6:06 PM, Thomas 'Pointed Head' Lahn wrote:
>>> Erwin Moller wrote:
>
> <snip>
>
>>>> Free advise: You might consider putting that in your sig.
>>> ^c
>>>
>>> Too long; a sig should not exceed 4 lines à 80 characters. Also, I
>>> would
>>> have to remove “Zend Certified PHP Engineer” from it, thereby an
>>> important
>>> hint that I am also qualified to make such statements as I did
>>> elsewhere in
>>> my posting.
>>>
>>
>> More nonsense from the pedantic troll. This is not your personal
>> newsgroup.
>
> Neither is it /anyone's/ personal newsgroup, which is why we have
> long-established conventions, known as "Netiquette", to help us to get
> along better in email and on Usenet.
>
> One of those conventions, which was codified twenty years ago and
> already well-established before that, is that sig blocks should not
> exceed four lines of sixty-five characters.
>

First of all, that convention was more than 20 years ago. At that time
Usenet was a lot more active and most people were using modems. There
is very little usenet traffic now, and most people are using broadband.
Bitching about a 5 line sig vs. a 4 line sig are just being pedantic.
But Pointed Head is well known for that.

> Another is: "Don't get involved in flame wars. Neither post nor respond
> to incendiary material." (And here's me doing just that.)
>

Then I suggest you keep out of it. Pointed Head is a well-known troll
in several newsgroups - not just this one.

> There is an argument for allowing longer sig blocks nowadays, with
> increased bandwidth availability and so on, but it's a lot harder to
> justify constant bickering. Could I suggest that you folks try the
> following every time you see something written by the other that you
> disagree with: (1) try to write your reply as if the original article
> had been written by a close and dear relative whom you don't wish to
> offend, but whom needs putting right on a technical matter; (2) try to
> find a way to end on a positive note. It might be less exciting for you,
> but it will make much better reading in the archives. In the mirror of
> history, flame wars *always* look bad.
>

Nice idea, but it's been tried before with the troll. It doesn't work.

[Richard Heathfield]

Nevertheless, it still makes sense for there to be a limit, does there not?

> Bitching about a 5 line sig vs. a 4 line sig are just being pedantic.

Pedantry is a Good Thing in a programmer. Getting it right is actually
rather important. People who don't care about little details like that
generally don't make good programmers.

> But Pointed Head is well known for that.

Noting the tone of your reply to my appeal for reason, common sense, and
civility has taught me something important. Thank you.

<snip>

>> Could I suggest that you folks try the
>> following every time you see something written by the other that you
>> disagree with: (1) try to write your reply as if the original article
>> had been written by a close and dear relative whom you don't wish to
>> offend, but whom needs putting right on a technical matter; (2) try to
>> find a way to end on a positive note. It might be less exciting for you,
>> but it will make much better reading in the archives. In the mirror of
>> history, flame wars *always* look bad.
>>
>
> Nice idea, but it's been tried before with the troll. It doesn't work.

You have just supplied ample evidence, so I can hardly fault your
conclusion.

[Thomas 'PointedEars' Lahn]

Richard Heathfield wrote:

> On 24/06/15 14:21, Jerry Stuckle wrote:
>> Bitching about a 5 line sig vs. a 4 line sig are just being pedantic.
>
> Pedantry is a Good Thing in a programmer. Getting it right is actually
> rather important. People who don't care about little details like that
> generally don't make good programmers.

JFTR: I did not even “bitch” about anyone else’s signature. I said that if
I modified *my* signature as suggested by Erwin, it would no longer comply
with Usenet convention. That was in part tongue-in-cheek of course, because
the suggestion itself was not to be taken seriously. Nuff said.

[Jerry Stuckle]

Whatever you say. You're the boss.

>> Bitching about a 5 line sig vs. a 4 line sig are just being pedantic.
>
> Pedantry is a Good Thing in a programmer. Getting it right is actually
> rather important. People who don't care about little details like that
> generally don't make good programmers.
>
>> But Pointed Head is well known for that.
>
> Noting the tone of your reply to my appeal for reason, common sense, and
> civility has taught me something important. Thank you.
>

Noting that you jumped into a conversation you had no part of to support
a widely known troll has also taught me something important. Thank you.

> <snip>
>
>>> Could I suggest that you folks try the
>>> following every time you see something written by the other that you
>>> disagree with: (1) try to write your reply as if the original article
>>> had been written by a close and dear relative whom you don't wish to
>>> offend, but whom needs putting right on a technical matter; (2) try to
>>> find a way to end on a positive note. It might be less exciting for you,
>>> but it will make much better reading in the archives. In the mirror of
>>> history, flame wars *always* look bad.
>>>
>>
>> Nice idea, but it's been tried before with the troll. It doesn't work.
>
> You have just supplied ample evidence, so I can hardly fault your
> conclusion.
>

Just look him up. Check comp.lang.javascript, for instance (where I
don't hang out - but Pointed Head has been all but kicked out of).

[Richard Heathfield]

On 24/06/15 20:21, Jerry Stuckle wrote:
> On 6/24/2015 1:48 PM, Richard Heathfield wrote:
>> On 24/06/15 14:21, Jerry Stuckle wrote:

<snip>

>>> First of all, that [sig block length] convention was [established] more

>>> than 20 years ago. At that time
>>> Usenet was a lot more active and most people were using modems. There
>>> is very little usenet traffic now, and most people are using broadband.
>>
>> Nevertheless, it still makes sense for there to be a limit, does there not?
>
> Whatever you say. You're the boss.

No, I'm not. Neither are you. That's why we have standards.

>>> Bitching about a 5 line sig vs. a 4 line sig are just being pedantic.
>>
>> Pedantry is a Good Thing in a programmer. Getting it right is actually
>> rather important. People who don't care about little details like that
>> generally don't make good programmers.
>>
>>> But Pointed Head is well known for that.
>>
>> Noting the tone of your reply to my appeal for reason, common sense, and
>> civility has taught me something important. Thank you.
>
> Noting that you jumped into a conversation you had no part of to support
> a widely known troll has also taught me something important. Thank you.

Usenet is a public discussion forum, and everyone is part of every
conversation. If we want private conversations, we use email.

[Richard Heathfield]

On 24/06/15 19:55, Thomas 'PointedEars' Lahn wrote:
> Richard Heathfield wrote:
>
>> On 24/06/15 14:21, Jerry Stuckle wrote:
>>> Bitching about a 5 line sig vs. a 4 line sig are just being pedantic.
>>
>> Pedantry is a Good Thing in a programmer. Getting it right is actually
>> rather important. People who don't care about little details like that
>> generally don't make good programmers.
>
> JFTR: I did not even “bitch” about anyone else’s signature. I said that if
> I modified *my* signature as suggested by Erwin, it would no longer comply
> with Usenet convention.

That's right, and it had not gone unnoticed. It seemed to me to be a
perfectly reasonable observation, which is why I chipped in.

Thanks for your constructive and moderate reply.

Okay, now it's time to take the bull by the horns and start a new
thread. This interchange has actually been quite instructive, in that it
gives me a clue about what to expect when I do so.

[Arno Welzel]

Jerry Stuckle:

> On 6/23/2015 7:45 PM, Thomas 'Pointed Head' Lahn wrote:

[...]

>> As for Usenet signature recommendations, see
>>
>> <https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>
>>
>> and
>>
>> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.
>>
>
> And you're the only one on this newsgroup who gives a damn about it.

Nope - I do too. That's the reason why I limit my signature to four
lines. Many other posts here also just have 4 lines or less in their
signature. These extra "==================" in your signature are just
needless.

But this fits the invalid sender address and the need for explanations
how one can reply to your real address <jstu...@attglobal.net>.

> But then you're the only pedantic troll who thinks they own the group,
> and everyone should follow your "rules"/

JFTR:
<http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>
is a text by the University of Manchester. If you want to blame someone
for these "rules", then go there.


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

[Jerry Stuckle]

On 6/25/2015 11:18 AM, Arno Welzel wrote:
> Jerry Stuckle:
>
>> On 6/23/2015 7:45 PM, Thomas 'Pointed Head' Lahn wrote:
> [...]
>>> As for Usenet signature recommendations, see
>>>
>>> <https://en.wikipedia.org/wiki/Signature_block#Signatures_in_Usenet_postings>
>>>
>>> and
>>>
>>> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>.
>>>
>>
>> And you're the only one on this newsgroup who gives a damn about it.
>
> Nope - I do too. That's the reason why I limit my signature to four
> lines. Many other posts here also just have 4 lines or less in their
> signature. These extra "==================" in your signature are just
> needless.
>
> But this fits the invalid sender address and the need for explanations
> how one can reply to your real address <jstu...@attglobal.net>.
>

Ah, another troll speaks up. Proven because he purposely tries to get
my email address spammed.

Sorry, sucker - it is not required you have a valid email address - only
one which can be easily decoded.

>> But then you're the only pedantic troll who thinks they own the group,
>> and everyone should follow your "rules"/
>
> JFTR:
> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>
> is a text by the University of Manchester. If you want to blame someone
> for these "rules", then go there.
>
>

Yup, just another troll - and another pedantic one, also.

Now go tell your mommy to wash your mouth out with soap.

[Jerry Stuckle]

On 6/25/2015 11:18 AM, Arno Welzel wrote:
>

> Nope - I do too. That's the reason why I limit my signature to four
> lines. Many other posts here also just have 4 lines or less in their
> signature. These extra "==================" in your signature are just
> needless.
>
> But this fits the invalid sender address and the need for explanations
> how one can reply to your real address <jstu...@attglobal.net>.
>

Actually, I need to rephrase that. Anyone who is so mean as to post
someone else's real address needs serious psychiatric help. It's not
something reasonable people do.

But we already knew that.

[Arno Welzel]

Jerry Stuckle:

> On 6/25/2015 11:18 AM, Arno Welzel wrote:
>>
>> Nope - I do too. That's the reason why I limit my signature to four
>> lines. Many other posts here also just have 4 lines or less in their
>> signature. These extra "==================" in your signature are just
>> needless.
>>
>> But this fits the invalid sender address and the need for explanations
>> how one can reply to your real address <jstu...@attglobal.net>.
>>
>
> Actually, I need to rephrase that. Anyone who is so mean as to post
> someone else's real address needs serious psychiatric help. It's not
> something reasonable people do.

Reasonable people don't need to use an "obfuscated" sender adresses.
Just look around - how many people here except you use this kind of
"obfuscation" and ask others to replace or remove parts of the invalid
address? If you are not able to use a mail server with proper spam
filtering it's your problem, not mine.

[Arno Welzel]

Am 2015-06-26 um 02:31 schrieb Jerry Stuckle:

[...]

> Sorry, sucker - it is not required you have a valid email address - only
> one which can be easily decoded.

See <https://tools.ietf.org/html/rfc1036>:

2.1. Required Header lines

2.1.1. From

The "From" line contains the electronic mailing address of the
person who sent the message, in the Internet syntax. It may
optionally also contain the full name of the person, in parentheses,
after the electronic address.
[...]


I don't see anything like "does not need to be the valid address, as
long as humans can decode it somehow manually".

Also the draft for the son of RFC1036 does not contain anything like
this - see
<http://www.chemie.fu-berlin.de/outerspace/netnews/son-of-1036.html#5.2>:

"The From header contains the electronic address, and possibly the full
name, of the article's author
[...]
The address SHOULD be a valid and complete Internet domain address,
capable of being successfully mailed to by an Internet host [...]"


Again no word about "may be invalid as long as a human is able to decode
it somehow".

But I know what will follow now: You will explain that RFC1036 is quite
old, the draft is also really old and they do not fit current needs and
therefore are not valid any longer.

Of course you would never write your own RFC draft to straighten this
out - because RFCs asking for a valid e-mail address or to keep
signatures within reasonable limits are for pedantic trolls - aren't they?

[Jerry Stuckle]

It actually was quite common a few years back, when Usenet was more
active. And it's a lot better than posting an invalid email address, as
many people do. But if you can't follow a simple instruction like
dropping a single character from an email address, you have other
problems. But that's OK - I don't want email from the likes of you, anyway.

But then anyone who is so mean as to post someone else's real address
needs serous psychiatric help. It's not something reasonable people do.

[Arno Welzel]

Am 2015-06-26 um 12:48 schrieb Jerry Stuckle:

> On 6/26/2015 4:21 AM, Arno Welzel wrote:

[...]

>> Reasonable people don't need to use an "obfuscated" sender adresses.
>> Just look around - how many people here except you use this kind of
>> "obfuscation" and ask others to replace or remove parts of the invalid
>> address? If you are not able to use a mail server with proper spam
>> filtering it's your problem, not mine.
>
> It actually was quite common a few years back, when Usenet was more
> active. And it's a lot better than posting an invalid email address, as
> many people do. But if you can't follow a simple instruction like
> dropping a single character from an email address, you have other
> problems. But that's OK - I don't want email from the likes of you, anyway.

In the last 15 years it was not "quite common". Maybe it was common in
the mid 1990ies or earlier in your world. But then I wonder, why RFCs
from that time ask for valid sender addresses, if it was common *not* to
use valid addresses. Do the RFC authors try to convince people to do
stupid things which make no sense in the real world? I don't think so.

> But then anyone who is so mean as to post someone else's real address
> needs serous psychiatric help. It's not something reasonable people do.

So why did you then quote the parts of my posts with your own address
over and over again, if you don't want it to be published as part of
Usenet messages?

[Jerry Stuckle]

On 6/26/2015 7:48 AM, Arno Welzel wrote:
> Am 2015-06-26 um 12:48 schrieb Jerry Stuckle:
>
>> On 6/26/2015 4:21 AM, Arno Welzel wrote:
> [...]
>>> Reasonable people don't need to use an "obfuscated" sender adresses.
>>> Just look around - how many people here except you use this kind of
>>> "obfuscation" and ask others to replace or remove parts of the invalid
>>> address? If you are not able to use a mail server with proper spam
>>> filtering it's your problem, not mine.
>>
>> It actually was quite common a few years back, when Usenet was more
>> active. And it's a lot better than posting an invalid email address, as
>> many people do. But if you can't follow a simple instruction like
>> dropping a single character from an email address, you have other
>> problems. But that's OK - I don't want email from the likes of you, anyway.
>
> In the last 15 years it was not "quite common". Maybe it was common in
> the mid 1990ies or earlier in your world. But then I wonder, why RFCs
> from that time ask for valid sender addresses, if it was common *not* to
> use valid addresses. Do the RFC authors try to convince people to do
> stupid things which make no sense in the real world? I don't think so.
>

Back in the days the RFC was written, there were no problems with SPAM
and SPAMBOTS mining usenet for email addresses. A simple CAPTCHA like
this is not out of line. The valid email address can easily be
determined by a human, satisfying the intent of the RFC.

>> But then anyone who is so mean as to post someone else's real address
>> needs serous psychiatric help. It's not something reasonable people do.
>
> So why did you then quote the parts of my posts with your own address
> over and over again, if you don't want it to be published as part of
> Usenet messages?
>
>

Once your sick mind posted it, it made no difference. But I would
suggest you seek psychiatric help. You are one sick person.

[Thomas 'PointedEars' Lahn]

Arno Welzel wrote:

> JFTR:
> <http://tools.ietf.org/html/draft-ietf-usefor-useage-01#section-3.1.2.1>
> is a text by the University of Manchester.

JFTR: It is not. It is an IETF Usenet Article Standard Update (usefor)
working group’s [1] working draft written by Charles H. Lindsey *of* the
University of Manchester. That he is working at that university carries no
weight whatsoever within the IETF; anyone can write an Internet Draft and
submit it to the IETF (example: RFC 4329, by Björn Höhrmann, which caused
some controversy afterwards). It should also be noted that this particular
working draft has expired “in September 2005”, and that said working group
is concluded (as it has produced “a standards-track successor to RFC 1036”
[ibid.]). If the relevant text has made it into an RFC or STD (Internet
standard), I have not found that one yet.

However, Mr. Lindsey is also the co-author of what is now RFC 5536, the
successor of RFC 1849 (“son of RFC 1036”), and of RFC 5537. *That* carries
weight because those have been and are today the Internet (quasi-)standards
that define Network News, the protocols underlying Usenet. Also, he is a
renowned computer scientist; the Web (for example, Wikipedia), has more
about him. Finally, he is actively participating in the administration of
newsgroups (see e.g. Google Groups for his postings). So it is reasonable
to assume, and I see that confirmed by the other follow-ups, that he does
know what he is writing about in there about Usenet signatures.

[1] <https://datatracker.ietf.org/wg/usefor/charter/>

[Thomas 'PointedEars' Lahn]

Arno Welzel wrote:

> Am 2015-06-26 um 02:31 schrieb Jerry Stuckle:
> [...]
>> Sorry, sucker - it is not required you have a valid email address - only
>> one which can be easily decoded.

Nonsense.

> See <https://tools.ietf.org/html/rfc1036>:

| Obsoleted by: 5536, 5537

> I don't see anything like "does not need to be the valid address, as
> long as humans can decode it somehow manually".

And indeed, there is not.

> Also the draft for the son of RFC1036 […]
> <http://www.chemie.fu-berlin.de/outerspace/netnews/son-of-1036.html#5.2>:

Long expired; not to be cited as reference material anyway:

| Internet Drafts are draft documents valid for a maximum of six months.
| Internet Drafts may be updated, replaced, or obsoleted by other documents
| at any time. It is not appropriate to use Internet Drafts as reference
| material or to cite them other than as a "working draft" or "work in
| progress".

And nowadays even the “Son of (RFC) 1036” is obsolete:

| Independent Submission H. Spencer
| Request for Comments: 1849 SP Systems
| Obsoleted by: 5536, 5537 March 2010
^^^^^^^^^^^^^^^^^^^^^^^^
| Category: Historic
| ISSN: 2070-1721
|
|
| "Son of 1036": News Article Format and Transmission

> But I know what will follow now: You will explain that RFC1036 is quite
> old, the draft is also really old

Not only really old; they are *obsolete* and *expired*, respectively, which
is quite a different thing. (RFC 2616 – HTTP/1.1 – of 1999 is "really old"
now, but implemented and still valid.)

But:

The (currently) Proposed Standard RFC 5536 of 2009 CE, which obsoletes RFCs
1036 and 1849, and has not been obsoleted itself yet – so it for all intents
and purposes it *is* *the* Internet standard on this –, makes no allowances
in this matter:

| 3.1.2. From
|
| The From header field is the same as that specified in Section 3.6.2
| of [RFC5322], with the added restrictions detailed above in
| Section 2.2.
|
| from = "From:" SP mailbox-list CRLF

The referred section 3.6.2 of RFC 5322 (“Internet Message Format”) says
explicitly:

| In all cases, the "From:" field SHOULD NOT contain any mailbox that
| does not belong to the author(s) of the message. See also section
| 3.6.3 for more information on forming the destination addresses for a
| reply.

I have only read in some IETF document (could have been an RFC, maybe even
on the Standards Track) that using the “invalid” TLD in some address header
fields would be allowed. I have forgotten which one (RFC 2606 is _not_ it),
and I have not found it again yet. Hints are appreciated.

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:

> I have only read in some IETF document (could have been an RFC, maybe even
> on the Standards Track) that using the “invalid” TLD in some address
> header fields would be allowed. I have forgotten which one (RFC 2606 is
> _not_ it), and I have not found it again yet. Hints are appreciated.

Found it:

,-<https://tools.ietf.org/html/rfc5537#section-3.4>
|
| 3.4. Duties of a Posting Agent
|
| […]
| Contrary to [RFC5322], which implies that the mailbox or mailboxes in
| the From header field should be that of the poster or posters, a
| poster who does not, for whatever reason, wish to use his own mailbox
| MAY use any mailbox ending in the top-level domain ".invalid"
| [RFC2606].

That, too, is part of a Proposed Standard. I find that unfortunate.

However, it *also* does not mean that address munging would have to be
accepted, that it would not be anti-social behavior anymore. It is only a
“MAY” (see RFC 2119 for the definition), and RFCs regard only the technical
side of communication. There is also a social side to it: “Internet is the
thing with cables; Usenet is the thing with *people*”. The author of

<http://www.interhack.net/pubs/munging-harmful/>

has confirmed publicly recently that he is still standing by those
statements, and there are not only a few people who agree with that.
(Especially as spam filters are getting better.)

The “invalid” TLD only *can* make it easier to recognize pseudo-addresses
(not everyone’s native language is English, not everyone knows about
Internet protocols, not everyone sees the automatically chosen receiver
field values); up to the point of filtering out all the offending messages
in the first place (which I still do).

[Arno Welzel]

(Cc: the contact of Eternal September)

Jerry Stuckle schrieb am 2015-06-26 um 20:29:

> On 6/26/2015 7:48 AM, Arno Welzel wrote:

[...]

>> In the last 15 years it was not "quite common". Maybe it was common in
>> the mid 1990ies or earlier in your world. But then I wonder, why RFCs
>> from that time ask for valid sender addresses, if it was common *not* to
>> use valid addresses. Do the RFC authors try to convince people to do
>> stupid things which make no sense in the real world? I don't think so.
>>
>
> Back in the days the RFC was written, there were no problems with SPAM
> and SPAMBOTS mining usenet for email addresses. A simple CAPTCHA like
> this is not out of line. The valid email address can easily be
> determined by a human, satisfying the intent of the RFC.

BTW: You use eternal-september.org - did you ever read their terms of use?

<http://www.eternal-september.org/index.php?showpage=terms>

Quote:

Users of the news server news.eternal-september.org are obliged to abide
by the following rules. Failure to do so will cause immediate
termination of access rights without prior notice.

* Sender Address

The e-mail addresses given in "From:", "Reply-To:", and "Sender:"
SHOULD be yours (i.e. you should be entitled to use it) and SHOULD be
valid (= should not bounce because of invalidity). Using addresses
and name space of other people without their consent is prohibited.

(unquote)

So - to use the services of eternal-september.org it is *required* to
use a valid sender address or the TLD ".invalid" according to RFC5537 by
2009(!) (<http://www.rfc-editor.org/rfc/rfc5537.txt>) which replaced
RFC1036 and SON-OF-RFC1036.

You may not like these rules. But this does not mean, you can just
ignore them by using an invalid address and call other people "pedantic
trolls" and "sick".

[Jerry Stuckle]

Right. SHOULD be yours and SHOULD be valid. I'm not violating any T&C.

> (unquote)
>
> So - to use the services of eternal-september.org it is *required* to
> use a valid sender address or the TLD ".invalid" according to RFC5537 by
> 2009(!) (<http://www.rfc-editor.org/rfc/rfc5537.txt>) which replaced
> RFC1036 and SON-OF-RFC1036.
>

You don't understand plain English very well, do you (even though it
isn't your native language, the wording is VERY CLEAR). But then those
in need of psychiatric care are like that.

> You may not like these rules. But this does not mean, you can just
> ignore them by using an invalid address and call other people "pedantic
> trolls" and "sick".
>
>

I'm not ignoring them. And I'm only calling a sick troll what he is.
You don't like it? Then get the help you so badly need.

[Peter H. Coffin]

On Sat, 27 Jun 2015 14:49:55 +0200, Arno Welzel wrote:
> Quote:
>
> Users of the news server news.eternal-september.org are obliged to abide
> by the following rules. Failure to do so will cause immediate
> termination of access rights without prior notice.
>
> * Sender Address
>
> The e-mail addresses given in "From:", "Reply-To:", and "Sender:"
> SHOULD be yours (i.e. you should be entitled to use it) and SHOULD be
> valid (= should not bounce because of invalidity). Using addresses
> and name space of other people without their consent is prohibited.
>
> (unquote)
>
> So - to use the services of eternal-september.org it is *required* to
> use a valid sender address or the TLD ".invalid" according to RFC5537 by
> 2009(!) (<http://www.rfc-editor.org/rfc/rfc5537.txt>) which replaced
> RFC1036 and SON-OF-RFC1036.

"should" != "must". Conventions of use of "may", "should", and "must"
are established in many RFC, including the elsewhere-mentioned
son-of-1036.

--
The Write Many, Read Never drive. For those people that don't know
their system has a /dev/null already.
-- Rik Steenwinkel, singing the praises of 8mm Exabytes

[Arno Welzel]

Jerry Stuckle schrieb am 2015-06-27 um 16:25:

> On 6/27/2015 8:49 AM, Arno Welzel wrote:

[...]
>> <http://www.eternal-september.org/index.php?showpage=terms>
[...]

> Right. SHOULD be yours and SHOULD be valid. I'm not violating any T&C.

Did you really read it? SHOULD is only there because using the TLD
".invalid" is also accepted.

Furthermore:

"Using addresses and name space of other people without their consent is
prohibited."

Is "jstu...@attglobal.net" *your* address?

[Arno Welzel]

Peter H. Coffin schrieb am 2015-06-28 um 05:14:
> On Sat, 27 Jun 2015 14:49:55 +0200, Arno Welzel wrote:
>> Quote:
>>
>> Users of the news server news.eternal-september.org are obliged to abide
>> by the following rules. Failure to do so will cause immediate
>> termination of access rights without prior notice.
>>
>> * Sender Address
>>
>> The e-mail addresses given in "From:", "Reply-To:", and "Sender:"
>> SHOULD be yours (i.e. you should be entitled to use it) and SHOULD be
>> valid (= should not bounce because of invalidity). Using addresses
>> and name space of other people without their consent is prohibited.
>>
>> (unquote)
>>
>> So - to use the services of eternal-september.org it is *required* to
>> use a valid sender address or the TLD ".invalid" according to RFC5537 by
>> 2009(!) (<http://www.rfc-editor.org/rfc/rfc5537.txt>) which replaced
>> RFC1036 and SON-OF-RFC1036.
>
> "should" != "must". Conventions of use of "may", "should", and "must"
> are established in many RFC, including the elsewhere-mentioned
> son-of-1036.

I know.

See <https://www.ietf.org/rfc/rfc2119.txt>:

3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

I don't think, Mr. Stuckle did carefully weigh the full implications his
decisions.

[Jerry Stuckle]

On 6/28/2015 11:52 AM, Arno Welzel wrote:
> Jerry Stuckle schrieb am 2015-06-27 um 16:25:
>
>> On 6/27/2015 8:49 AM, Arno Welzel wrote:
> [...]
>>> <http://www.eternal-september.org/index.php?showpage=terms>
> [...]
>> Right. SHOULD be yours and SHOULD be valid. I'm not violating any T&C.
>
> Did you really read it? SHOULD is only there because using the TLD
> ".invalid" is also accepted.
>
> Furthermore:
>
> "Using addresses and name space of other people without their consent is
> prohibited."
>
> Is "jstu...@attglobal.net" *your* address?
>
>
>

Yup, but I'm not using the name space of anyone else. It doesn't have
to be MY address - just no one else's. So much for the psychotic troll.

You really need psychiatric help. I hope you seek it.

[Jerry Stuckle]

You have no idea what I weighed. You just jumped on me - like the
psychotic troll you are.

I really hope you get the psychiatric help you so desperately need.

[Arno Welzel]

Am 2015-06-29 um 02:10 schrieb Jerry Stuckle:

> On 6/28/2015 11:54 AM, Arno Welzel wrote:

[...]

>> See <https://www.ietf.org/rfc/rfc2119.txt>:
>>
>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
>> may exist valid reasons in particular circumstances to ignore a
>> particular item, but the full implications must be understood and
>> carefully weighed before choosing a different course.
>>
>> I don't think, Mr. Stuckle did carefully weigh the full implications his
>> decisions.
>>
>>
>
> You have no idea what I weighed. You just jumped on me - like the
> psychotic troll you are.

JFTR: It was *you* claiming that nobody cares about the RFCs about the
requirements for usenet messages and it is *you* ignoring the
recommendations, not me.

[Jerry Stuckle]

On 6/30/2015 3:54 AM, Arno Welzel wrote:
> Am 2015-06-29 um 02:10 schrieb Jerry Stuckle:
>
>> On 6/28/2015 11:54 AM, Arno Welzel wrote:
> [...]
>>> See <https://www.ietf.org/rfc/rfc2119.txt>:
>>>
>>> 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
>>> may exist valid reasons in particular circumstances to ignore a
>>> particular item, but the full implications must be understood and
>>> carefully weighed before choosing a different course.
>>>
>>> I don't think, Mr. Stuckle did carefully weigh the full implications his
>>> decisions.
>>>
>>>
>>
>> You have no idea what I weighed. You just jumped on me - like the
>> psychotic troll you are.
>
> JFTR: It was *you* claiming that nobody cares about the RFCs about the
> requirements for usenet messages and it is *you* ignoring the
> recommendations, not me.
>

I never said nobody cares about the RFCs about the requirements for
usenet messages. You can't put words into my mouth.

But then nobody cares what a psychotic troll thinks, Arno. Now why
don't you go running to your mommy and let the adults carry on discussions.

[Arno Welzel]

Am 2015-06-30 um 14:45 schrieb Jerry Stuckle:

[...]

> But then nobody cares what a psychotic troll thinks, Arno. Now why

It seems YOU do.

[Jerry Stuckle]

On 6/30/2015 10:20 AM, Arno Welzel wrote:
> Am 2015-06-30 um 14:45 schrieb Jerry Stuckle:
>
> [...]
>> But then nobody cares what a psychotic troll thinks, Arno. Now why
>
> It seems YOU do.
>
>

Not a bit, Arno. You flatter yourself too much.

Just because I respond to a psychotic troll doesn't mean I give a damn
about what you have to say. It's very much for the benefit of others
who might look at this group and not know what you are.

[Denis McMahon]

On Sat, 27 Jun 2015 22:14:20 -0500, Peter H. Coffin wrote:

> "should" != "must". Conventions of use of "may", "should", and "must"
> are established in many RFC, including the elsewhere-mentioned
> son-of-1036.

Don't assume that specific defined meanings of certain words used in RFCs
also apply to those same words when used in the T&C of a provider.

--
Denis McMahon, denismf...@gmail.com

[Arno Welzel]

Am 2015-06-30 um 21:00 schrieb Jerry Stuckle:

> On 6/30/2015 10:20 AM, Arno Welzel wrote:
>> Am 2015-06-30 um 14:45 schrieb Jerry Stuckle:
>>
>> [...]
>>> But then nobody cares what a psychotic troll thinks, Arno. Now why
>>
>> It seems YOU do.
>>
>>
>
> Not a bit, Arno. You flatter yourself too much.
>
> Just because I respond to a psychotic troll doesn't mean I give a damn
> about what you have to say. It's very much for the benefit of others
> who might look at this group and not know what you are.

At least others also learn how friendly and kind you are calling others
"psychotic trolls" and ask them to get psychiatric help and "go running
to your mommy and let the adults carry on discussions" etc.

I wonder who is the childish person here... the last time someone tried
(and did not succeed) to make me angry by saying "go running to your
mommy" to me was in primary school.

BTW: F'up to poster.

[Jerry Stuckle]

Let's see here... someone who throws a fit and purposely demunges
someone else's email address to allow that address to be harvested by
spammers... Then tries to get the last word in a newsgroup by changing
the reply-to. Sounds to me like something a child or psychotic person
would do. Or one who's both, like you.

I wonder who's the child here? Better go running to your mommy and tell
her how the mean old man called you what you are!

And others will see you for what you really are - and understand why I
stand up to you instead of caving like you want.

[Richard Heathfield]

On 06/07/15 16:56, Jerry Stuckle wrote:
> On 7/6/2015 7:36 AM, Arno Welzel wrote:

<snip>

>> BTW: F'up to poster.
>
> Let's see here... someone who throws a fit and purposely demunges
> someone else's email address to allow that address to be harvested by
> spammers...

You have no evidence that he threw a fit, and you don't know that the
reason you guessed at was actually his reason for posting your correct
email address (which he is perfectly within his rights to do, and which
does not, generally speaking, result in an increase in spam emails to
that address). So you're just making stuff up.

> Then tries to get the last word in a newsgroup by changing
> the reply-to.

Since the thread has descended into abusive name-calling, attempting to
switch to email is actually a reasonable thing to do: "- If you should
find yourself in a disagreement with one person, make your responses to
each other via mail rather than continue to send messages to the list or
the group. If you are debating a point on which the group might have
some interest, you may summarize for them later" (RFC1855). Arno's
process for attempting to do this (setting followups and warning you
that he had done so) was perfectly correct.

> Sounds to me like something a child or psychotic person
> would do. Or one who's both, like you.

Abusive name-calling may be good for your blood pressure, but it doesn't
move the debate on. Arno does not strike me as being either childish or
child-like, and I see no evidence here that would justify a diagnosis of
"psychotic". If you are not medically qualified, you have no basis for
the adjective other than that of hyperbole (in which case, learn some
new adjectives). If you /are/ medically qualified, you should know
better than to offer a hasty and intemperate diagnosis over Usenet.

> I wonder who's the child here?

Tell ya what, let's find out...

> Better go running to your mommy and tell
> her how the mean old man called you what you are!

...well, that answered /that/ question!

> And others will see you for what you really are - and understand why I
> stand up to you instead of caving like you want.

Arno seems to me to be behaving like a grown-up. He is making sensible,
dispassionate points in a neutral way. If you don't want to do your
reputation (such as it is) any more damage, I suggest emulating him.

--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[Jerry Stuckle]

On 7/6/2015 1:54 PM, Richard Heathfield wrote:
> On 06/07/15 16:56, Jerry Stuckle wrote:
>> On 7/6/2015 7:36 AM, Arno Welzel wrote:
> <snip>
>>> BTW: F'up to poster.
>>
>> Let's see here... someone who throws a fit and purposely demunges
>> someone else's email address to allow that address to be harvested by
>> spammers...
>
> You have no evidence that he threw a fit, and you don't know that the
> reason you guessed at was actually his reason for posting your correct
> email address (which he is perfectly within his rights to do, and which
> does not, generally speaking, result in an increase in spam emails to
> that address). So you're just making stuff up.
>

Wrong on two counts. If you would have read the post, you would see he
was throwing a fit. And why would he purposefully post an unmunged
email address if it weren't to allow it to be harvested by spammers?

Or maybe it's just something you would do, also.

>> Then tries to get the last word in a newsgroup by changing
>> the reply-to.
>
> Since the thread has descended into abusive name-calling, attempting to
> switch to email is actually a reasonable thing to do: "- If you should
> find yourself in a disagreement with one person, make your responses to
> each other via mail rather than continue to send messages to the list or
> the group. If you are debating a point on which the group might have
> some interest, you may summarize for them later" (RFC1855). Arno's
> process for attempting to do this (setting followups and warning you
> that he had done so) was perfectly correct.
>

If he wanted to stop it, he didn't have to post. But like all trolls,
he needs to have the last word.

>> Sounds to me like something a child or psychotic person
>> would do. Or one who's both, like you.
>
> Abusive name-calling may be good for your blood pressure, but it doesn't
> move the debate on. Arno does not strike me as being either childish or
> child-like, and I see no evidence here that would justify a diagnosis of
> "psychotic". If you are not medically qualified, you have no basis for
> the adjective other than that of hyperbole (in which case, learn some
> new adjectives). If you /are/ medically qualified, you should know
> better than to offer a hasty and intemperate diagnosis over Usenet.
>

I call them like I see them. Trolls are trolls. And psychos are psychos.

>> I wonder who's the child here?
>
> Tell ya what, let's find out...
>
>> Better go running to your mommy and tell
>> her how the mean old man called you what you are!
>
> ...well, that answered /that/ question!
>

Yup, he needs to go running to his mommy.

>> And others will see you for what you really are - and understand why I
>> stand up to you instead of caving like you want.
>
> Arno seems to me to be behaving like a grown-up. He is making sensible,
> dispassionate points in a neutral way. If you don't want to do your
> reputation (such as it is) any more damage, I suggest emulating him.
>

ROFLMAO! Only another third grader would consider Arno acting like a
grown-up.

Maybe you need to running to your mommy, too, and tell her the mean old
man called you a troll - troll!

Grow up!

[Richard Heathfield]

On 06/07/15 21:54, Jerry Stuckle wrote:
> On 7/6/2015 1:54 PM, Richard Heathfield wrote:
>> On 06/07/15 16:56, Jerry Stuckle wrote:
>>> On 7/6/2015 7:36 AM, Arno Welzel wrote:
>> <snip>
>>>> BTW: F'up to poster.
>>>
>>> Let's see here... someone who throws a fit and purposely demunges
>>> someone else's email address to allow that address to be harvested by
>>> spammers...
>>
>> You have no evidence that he threw a fit, and you don't know that the
>> reason you guessed at was actually his reason for posting your correct
>> email address (which he is perfectly within his rights to do, and which
>> does not, generally speaking, result in an increase in spam emails to
>> that address). So you're just making stuff up.
>>
>
> Wrong on two counts. If you would have read the post, you would see he
> was throwing a fit.

I did read it, and I saw no evidence of a fit.

> And why would he purposefully post an unmunged
> email address if it weren't to allow it to be harvested by spammers?

You'll have to ask him that, but the fact that you can't think of
another reason doesn't mean that no other reason exists.

> Or maybe it's just something you would do, also.

You have no rational grounds for that speculation.

>>> Then tries to get the last word in a newsgroup by changing
>>> the reply-to.
>>
>> Since the thread has descended into abusive name-calling, attempting to
>> switch to email is actually a reasonable thing to do: "- If you should
>> find yourself in a disagreement with one person, make your responses to
>> each other via mail rather than continue to send messages to the list or
>> the group. If you are debating a point on which the group might have
>> some interest, you may summarize for them later" (RFC1855). Arno's
>> process for attempting to do this (setting followups and warning you
>> that he had done so) was perfectly correct.
>>
>
> If he wanted to stop it, he didn't have to post. But like all trolls,
> he needs to have the last word.

Perhaps he wanted to continue the discussion with you, but without
burdening the newsgroup with it - a reasonable offer, which you
declined, de facto, by replying to the group rather than to email. It is
clear that you, too, wish to continue the discussion, because you don't
have to post either. As for the last word, on Usenet there really is no
such thing.

>
>>> Sounds to me like something a child or psychotic person
>>> would do. Or one who's both, like you.
>>
>> Abusive name-calling may be good for your blood pressure, but it doesn't
>> move the debate on. Arno does not strike me as being either childish or
>> child-like, and I see no evidence here that would justify a diagnosis of
>> "psychotic". If you are not medically qualified, you have no basis for
>> the adjective other than that of hyperbole (in which case, learn some
>> new adjectives). If you /are/ medically qualified, you should know
>> better than to offer a hasty and intemperate diagnosis over Usenet.
>>
>
> I call them like I see them. Trolls are trolls. And psychos are psychos.

Assertions are ten a penny on Usenet. Arno is not behaving like a troll.
As for "psycho", is that code for "someone who disagrees with Jerry
Stuckle"? If so, I suppose you must meet a /lot/ of psychos.

>>> I wonder who's the child here?
>>
>> Tell ya what, let's find out...
>>
>>> Better go running to your mommy and tell
>>> her how the mean old man called you what you are!
>>
>> ...well, that answered /that/ question!
>>
>
> Yup, he needs to go running to his mommy.

You reinforce my point nicely, although probably not intentionally.

<more nonsense snipped>

[Jerry Stuckle]

On 7/6/2015 7:00 PM, Richard Heathfield wrote:
> On 06/07/15 21:54, Jerry Stuckle wrote:
>> On 7/6/2015 1:54 PM, Richard Heathfield wrote:
>>> On 06/07/15 16:56, Jerry Stuckle wrote:
>>>> On 7/6/2015 7:36 AM, Arno Welzel wrote:
>>> <snip>
>>>>> BTW: F'up to poster.
>>>>
>>>> Let's see here... someone who throws a fit and purposely demunges
>>>> someone else's email address to allow that address to be harvested by
>>>> spammers...
>>>
>>> You have no evidence that he threw a fit, and you don't know that the
>>> reason you guessed at was actually his reason for posting your correct
>>> email address (which he is perfectly within his rights to do, and which
>>> does not, generally speaking, result in an increase in spam emails to
>>> that address). So you're just making stuff up.
>>>
>>
>> Wrong on two counts. If you would have read the post, you would see he
>> was throwing a fit.
>
> I did read it, and I saw no evidence of a fit.
>

ROFLMAO! You aren't very smart, are you?

>> And why would he purposefully post an unmunged
>> email address if it weren't to allow it to be harvested by spammers?
>
> You'll have to ask him that, but the fact that you can't think of
> another reason doesn't mean that no other reason exists.
>

Ah, but that's because you're not very smart.

>> Or maybe it's just something you would do, also.
>
> You have no rational grounds for that speculation.
>

You sure stick up for the troll, so one can only assume you approve of
his actions and would do the same thing. A logical conclusion.

>>>> Then tries to get the last word in a newsgroup by changing
>>>> the reply-to.
>>>
>>> Since the thread has descended into abusive name-calling, attempting to
>>> switch to email is actually a reasonable thing to do: "- If you should
>>> find yourself in a disagreement with one person, make your responses to
>>> each other via mail rather than continue to send messages to the list or
>>> the group. If you are debating a point on which the group might have
>>> some interest, you may summarize for them later" (RFC1855). Arno's
>>> process for attempting to do this (setting followups and warning you
>>> that he had done so) was perfectly correct.
>>>
>>
>> If he wanted to stop it, he didn't have to post. But like all trolls,
>> he needs to have the last word.
>
> Perhaps he wanted to continue the discussion with you, but without
> burdening the newsgroup with it - a reasonable offer, which you
> declined, de facto, by replying to the group rather than to email. It is
> clear that you, too, wish to continue the discussion, because you don't
> have to post either. As for the last word, on Usenet there really is no
> such thing.
>

Then he could have continued the discussion privately, instead of
posting in the forum and setting the FUP so he would get the last word
in the forum.

And yes, there is a last word - on usenet, just like other places in the
world. But trolls don't understand that.

>>
>>>> Sounds to me like something a child or psychotic person
>>>> would do. Or one who's both, like you.
>>>
>>> Abusive name-calling may be good for your blood pressure, but it doesn't
>>> move the debate on. Arno does not strike me as being either childish or
>>> child-like, and I see no evidence here that would justify a diagnosis of
>>> "psychotic". If you are not medically qualified, you have no basis for
>>> the adjective other than that of hyperbole (in which case, learn some
>>> new adjectives). If you /are/ medically qualified, you should know
>>> better than to offer a hasty and intemperate diagnosis over Usenet.
>>>
>>
>> I call them like I see them. Trolls are trolls. And psychos are
>> psychos.
>
> Assertions are ten a penny on Usenet. Arno is not behaving like a troll.
> As for "psycho", is that code for "someone who disagrees with Jerry
> Stuckle"? If so, I suppose you must meet a /lot/ of psychos.
>

Not behaving like a troll? ROFLMAO! I guess you think that's the case
because you act the same way. But the trolls of a feather...

And just disagreeing is not being psycho. Purposely trying to harm
someone by getting their email harvested by spammers IS psychotic. But
then you think what it did was ok, also... So psychotic trolls of a
feather...

>>>> I wonder who's the child here?
>>>
>>> Tell ya what, let's find out...
>>>
>>>> Better go running to your mommy and tell
>>>> her how the mean old man called you what you are!
>>>
>>> ...well, that answered /that/ question!
>>>
>>
>> Yup, he needs to go running to his mommy.
>
> You reinforce my point nicely, although probably not intentionally.
>
> <more nonsense snipped>
>

Yup, you need to go running to your mommy. Tell here the mean old man
called you a psychotic troll. Maybe she'll comfort you.

But then I see you're well-known in other newsgroups, also - such as
comp.lang.c, comp.programming, and others.

BTW - how did that "C" book you edited turn out? I see it was a
failure, too.

[Richard Heathfield]

On 07/07/15 03:08, Jerry Stuckle wrote:
> On 7/6/2015 7:00 PM, Richard Heathfield wrote:
>> On 06/07/15 21:54, Jerry Stuckle wrote:
>>> On 7/6/2015 1:54 PM, Richard Heathfield wrote:
>>>> On 06/07/15 16:56, Jerry Stuckle wrote:
>>>>> On 7/6/2015 7:36 AM, Arno Welzel wrote:
>>>> <snip>
>>>>>> BTW: F'up to poster.
>>>>>
>>>>> Let's see here... someone who throws a fit and purposely demunges
>>>>> someone else's email address to allow that address to be harvested by
>>>>> spammers...
>>>>
>>>> You have no evidence that he threw a fit, and you don't know that the
>>>> reason you guessed at was actually his reason for posting your correct

>>>> email address [...]. So you're just making stuff up.

>>>
>>> Wrong on two counts. If you would have read the post, you would see he
>>> was throwing a fit.
>>
>> I did read it, and I saw no evidence of a fit.
>>
>
> ROFLMAO! You aren't very smart, are you?

Maybe not, but I am at least smart enough to recognise when someone is
far more interested in hurling insults than in learning.

[Jerry Stuckle]

On 7/7/2015 2:24 AM, Richard Heathfield wrote:
> On 07/07/15 03:08, Jerry Stuckle wrote:
>> On 7/6/2015 7:00 PM, Richard Heathfield wrote:
>>> On 06/07/15 21:54, Jerry Stuckle wrote:
>>>> On 7/6/2015 1:54 PM, Richard Heathfield wrote:
>>>>> On 06/07/15 16:56, Jerry Stuckle wrote:
>>>>>> On 7/6/2015 7:36 AM, Arno Welzel wrote:
>>>>> <snip>
>>>>>>> BTW: F'up to poster.
>>>>>>
>>>>>> Let's see here... someone who throws a fit and purposely demunges
>>>>>> someone else's email address to allow that address to be harvested by
>>>>>> spammers...
>>>>>
>>>>> You have no evidence that he threw a fit, and you don't know that the
>>>>> reason you guessed at was actually his reason for posting your correct
>>>>> email address [...]. So you're just making stuff up.
>>>>
>>>> Wrong on two counts. If you would have read the post, you would see he
>>>> was throwing a fit.
>>>
>>> I did read it, and I saw no evidence of a fit.
>>>
>>
>> ROFLMAO! You aren't very smart, are you?
>
> Maybe not, but I am at least smart enough to recognise when someone is
> far more interested in hurling insults than in learning.
>

I guess that's why you're so good at it, troll.

[apoorv....@gmail.com]

Lo and behold we started with a response from a server and then we have a fight between users weather it's javascript or ECMA and then we have a fight about email.
after all this time my project is about to finish and it's going good I have to take a dedicated server.
all right every body time to let this thread die.