Google seems to think that all software HAS a user interface. Or even a user.

Synchronous server requests are a perfectly reasonable thing to do in some circumstances. And I agree with the author that such a decision belongs to the application developer, not the browser maker.

In article <9585d114-082a-49b0-9c3c-185708e2a256n@googlegroups.com>,
Robert Zeurunkl <bzeurunkl@gmail.com> wrote:
>
>Google seems to think that all software HAS a user interface. Or even a user.

Is Google that stupid?

>
>Synchronous server requests are a perfectly reasonable thing to do in some circumstances. And I agree with the author that such a decision belongs to the application developer, not the browser maker.
>

Hence async.
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
Look at Psalms 14 and 53 on Atheism https://www.empire.kred/ROOTNK?t=94a1f39b
Saying good things is evil when they are lies. -unknown Beware https://mindspring.com

The Doctor:

>>Synchronous server requests are a perfectly reasonable thing to do in
>>some circumstances. And I agree with the author that such a decision
>>belongs to the application developer, not the browser maker.
>>
>>
> Hence async.

Ehm, What's the name of the JS construct to blocking-wait for signals?

With more API calls becoming async-styled, the more difficult it becomes
to collect related pieces of code in a block. And keeping deeply nestedd
prenthesis in sync obviously also isn't very meaningful. And all this to
make websites use up a complete CPU.

Gruss

Jan Bruns

Robert Zeurunkl wrote:

> Synchronous server requests are a perfectly reasonable thing to do in
> some circumstances. And I agree with the author that such a decision
> belongs to the application developer, not the browser maker.

I think you misunderstand the relationship. Browser makers are in the
job of helping end users, not application developers. To convince a
browser maker to add, remove, or alter a feature, developers need to
demonstrate how it will be of benefit to users. If they cannot do so,
the vendor has no conceivable reason to make the change.

So to argue for future synchronous requests, you will need to show that
users will be better off if it's added.

The reason it was deprecated is that the vendors were convinced by
advocates for users that the risks to users significantly outweighed
the benefits. Sites that freeze waiting for a response that never
comes are considered a much bigger hazard than the inconvenience
caused to developers. Feel free to try to convince the community
otherwise. But I think it's a (very steep!) uphill battle.

-- Scott

Robert Zeurunkl:

> Google seems to think that all software HAS a user interface. Or
> even a user.

Which is the case as long as the request is executed in a browser.

> Synchronous server requests are a perfectly reasonable thing to do in
> some circumstances. And I agree with the author that such a decision
> belongs to the application developer, not the browser maker.

What kind of *browsers* don't have a user interface?

And using a request which blocks the whole UI until there is a response
from the server *is* a bad thing.

--
Arno Welzel
https://arnowelzel.de

On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:

> What kind of *browsers* don't have a user interface?

They are called Headless Browsers:

<https://en.wikipedia.org/wiki/Headless_browser>

Michael Haufe (TNO):

> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>
>> What kind of *browsers* don't have a user interface?
>
> They are called Headless Browsers:
>
> <https://en.wikipedia.org/wiki/Headless_browser>

Yes, I'm aware of this. But are these are relevant in this context? How
many applications use headless browsers *and* need to use XMLHttpRequest?

--
Arno Welzel
https://arnowelzel.de

On Saturday, June 25, 2022 at 5:47:44 PM UTC-5, Arno Welzel wrote:
> Michael Haufe (TNO):
> > On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
> >
> >> What kind of *browsers* don't have a user interface?
> >
> > They are called Headless Browsers:
> >
> > <https://en.wikipedia.org/wiki/Headless_browser>
> Yes, I'm aware of this. But are these are relevant in this context? How
> many applications use headless browsers *and* need to use XMLHttpRequest?

Applications that have an automated QA process use this often. You can test scenarios such as:

"When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"

You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM
such as PowerShell 7.

Michael Haufe (TNO):

> On Saturday, June 25, 2022 at 5:47:44 PM UTC-5, Arno Welzel wrote:
>> Michael Haufe (TNO):
>>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>>
>>>> What kind of *browsers* don't have a user interface?
>>>
>>> They are called Headless Browsers:
>>>
>>> <https://en.wikipedia.org/wiki/Headless_browser>
>> Yes, I'm aware of this. But are these are relevant in this context? How
>> many applications use headless browsers *and* need to use XMLHttpRequest?
>
> Applications that have an automated QA process use this often. You can test scenarios such as:
>
> "When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"

I dont't understand why this requires a syncronous XMLHttpRequest. Test
tools like Cypress can wait for events.

> You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM
> such as PowerShell 7.

And web scraping needs XMLHttpRequest? Why?

--
Arno Welzel
https://arnowelzel.de

On Sunday, June 26, 2022 at 12:02:27 PM UTC-5, Arno Welzel wrote:
> Michael Haufe (TNO):

> > Applications that have an automated QA process use this often. You can test scenarios such as:
> >
> > "When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"

> I dont't understand why this requires a syncronous XMLHttpRequest. Test
> tools like Cypress can wait for events.

> > You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM
> > such as PowerShell 7.

> And web scraping needs XMLHttpRequest? Why?

You seem to be drifting or making a point that wasn't expressed clearly.
Which question are you asking?

Is it about Headless Browsers + XHR or is it about Headless Browsers + Synchronous XHR?

You don't need synchronous XHR with the existence of async/await and events as you've mentioned.

For the web scraping: you don't *need* it, but if you have an anemic CLI or host environment, a DOM+JS environment can be far easier.

If I'm in a browser (headless or otherwise) I can near trivially walk the hyperlinks of the domain and collect information information such as email addresses. It's just a DFS or BFS walk. The XHR object even has the ability to provide a DOM as a result of a request directly without parsing.

Michael Haufe (TNO):

> On Sunday, June 26, 2022 at 12:02:27 PM UTC-5, Arno Welzel wrote:
>> Michael Haufe (TNO):
>
>>> Applications that have an automated QA process use this often. You can test scenarios such as:
>>>
>>> "When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"
>
>> I dont't understand why this requires a syncronous XMLHttpRequest. Test
>> tools like Cypress can wait for events.
>
>>> You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM
>>> such as PowerShell 7.
>
>> And web scraping needs XMLHttpRequest? Why?
>
> You seem to be drifting or making a point that wasn't expressed clearly.
> Which question are you asking?

My question was, why *synchronous* XHR is *required* for tests or web
scraping. I have done testing with headless browsers myself a lot and
never needed *synchronous* XHR ever.

Also "web scraping" means first of all just to send requests and wait
for the result. There is no issue at all if this is done with
asynchronous XHR.

> If I'm in a browser (headless or otherwise) I can near trivially walk
> the hyperlinks of the domain and collect information information such
> as email addresses. It's just a DFS or BFS walk. The XHR object even
> has the ability to provide a DOM as a result of a request directly
> without parsing.
And why does the XHR to be synchronous?

--
Arno Welzel
https://arnowelzel.de

On 25/06/2022 11:06, Arno Welzel wrote:
> What kind of*browsers* don't have a user interface?

Lib curl?

--
Future generations will wonder in bemused amazement that the early
twenty-first century’s developed world went into hysterical panic over a
globally average temperature increase of a few tenths of a degree, and,
on the basis of gross exaggerations of highly uncertain computer
projections combined into implausible chains of inference, proceeded to
contemplate a rollback of the industrial age.

Richard Lindzen

On 25/06/2022 23:47, Arno Welzel wrote:
> Michael Haufe (TNO):
>
>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>
>>> What kind of *browsers* don't have a user interface?
>>
>> They are called Headless Browsers:
>>
>> <https://en.wikipedia.org/wiki/Headless_browser>
>
> Yes, I'm aware of this. But are these are relevant in this context? How
> many applications use headless browsers *and* need to use XMLHttpRequest?
>
>
I've written a couple...

--
Future generations will wonder in bemused amazement that the early
twenty-first century’s developed world went into hysterical panic over a
globally average temperature increase of a few tenths of a degree, and,
on the basis of gross exaggerations of highly uncertain computer
projections combined into implausible chains of inference, proceeded to
contemplate a rollback of the industrial age.

Richard Lindzen

The Natural Philosopher:

> On 25/06/2022 11:06, Arno Welzel wrote:
>> What kind of*browsers* don't have a user interface?
>
> Lib curl?

This is not a browser. No, not every library which is able to send HTTP
requests and process the response is a "browser".

--
Arno Welzel
https://arnowelzel.de

The Natural Philosopher:

> On 25/06/2022 23:47, Arno Welzel wrote:
>> Michael Haufe (TNO):
>>
>>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>>
>>>> What kind of *browsers* don't have a user interface?
>>>
>>> They are called Headless Browsers:
>>>
>>> <https://en.wikipedia.org/wiki/Headless_browser>
>>
>> Yes, I'm aware of this. But are these are relevant in this context? How
>> many applications use headless browsers *and* need to use XMLHttpRequest?
>>
>>
> I've written a couple...

Can you name them? Or are they just relevant to yourself?

--
Arno Welzel
https://arnowelzel.de

On 28/06/2022 08:40, Arno Welzel wrote:
> The Natural Philosopher:
>
>> On 25/06/2022 11:06, Arno Welzel wrote:
>>> What kind of*browsers* don't have a user interface?
>>
>> Lib curl?
>
> This is not a browser. No, not every library which is able to send HTTP
> requests and process the response is a "browser".
>
>
Semantics.

--
“There are two ways to be fooled. One is to believe what isn’t true; the
other is to refuse to believe what is true.”

—Soren Kierkegaard

On 28/06/2022 08:41, Arno Welzel wrote:
> The Natural Philosopher:
>
>> On 25/06/2022 23:47, Arno Welzel wrote:
>>> Michael Haufe (TNO):
>>>
>>>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>>>
>>>>> What kind of *browsers* don't have a user interface?
>>>>
>>>> They are called Headless Browsers:
>>>>
>>>> <https://en.wikipedia.org/wiki/Headless_browser>
>>>
>>> Yes, I'm aware of this. But are these are relevant in this context? How
>>> many applications use headless browsers *and* need to use XMLHttpRequest?
>>>
>>>
>> I've written a couple...
>
> Can you name them? Or are they just relevant to yourself?
>
Oh, just relevant to myself. Ive written apps where the easiest solution
was to implement background tasks from browser to server to update parts
of the web page whilst a real time job - streaming videos TV or music -
was happening in 'foreground'

conceptually these tasks could be considered 'headless browsers', and
they certainly used AJAX style calls and call backs.

But redefining semantics to win arguments doesn't get sound code written
so if you want to challenge that you wont get a response out of me.

The philosophy part of my name means that I make clear distinctions at
all levels between Kant's 'things in themselves' , and our mental
*models* of them.

I don't give a flying fuck if my code is 'true object oriented' '
procedural' 'synchronous' or 'asynchronous' , 'multithreaded' or 'single
user' 'headless' 'tailless'..only that it not be 'pointless'.

I leave all that ego boosting semantics to computer scientists. I care
simply that it works to do the intended job. I am just an engineer.

--
“There are two ways to be fooled. One is to believe what isn’t true; the
other is to refuse to believe what is true.”

—Soren Kierkegaard

The Natural Philosopher:

> On 28/06/2022 08:41, Arno Welzel wrote:
>> The Natural Philosopher:
>>
>>> On 25/06/2022 23:47, Arno Welzel wrote:
>>>> Michael Haufe (TNO):
>>>>
>>>>> On Saturday, June 25, 2022 at 5:07:06 AM UTC-5, Arno Welzel wrote:
>>>>>
>>>>>> What kind of *browsers* don't have a user interface?
>>>>>
>>>>> They are called Headless Browsers:
>>>>>
>>>>> <https://en.wikipedia.org/wiki/Headless_browser>
>>>>
>>>> Yes, I'm aware of this. But are these are relevant in this context? How
>>>> many applications use headless browsers *and* need to use XMLHttpRequest?
>>>>
>>>>
>>> I've written a couple...
>>
>> Can you name them? Or are they just relevant to yourself?
>>
> Oh, just relevant to myself. Ive written apps where the easiest solution
> was to implement background tasks from browser to server to update parts
> of the web page whilst a real time job - streaming videos TV or music -
> was happening in 'foreground'
>
> conceptually these tasks could be considered 'headless browsers', and
> they certainly used AJAX style calls and call backs.
>
> But redefining semantics to win arguments doesn't get sound code written
> so if you want to challenge that you wont get a response out of me.

What do you mean with "redefining semantics"?

I just asked about the practical *requirement* for *synchronous*
XMLHttpRequest in headless browers which can not be solved with
*asynchronous* XMLHttpRequest.

I also asked if you can name the apps you have written, so one can see
their relevance. If something is only relevant for yourself than it does
not justify to keep the technology as a whole just because you
personally like to use it.

--
Arno Welzel
https://arnowelzel.de

The Natural Philosopher:

> On 28/06/2022 08:40, Arno Welzel wrote:
>> The Natural Philosopher:
>>
>>> On 25/06/2022 11:06, Arno Welzel wrote:
>>>> What kind of*browsers* don't have a user interface?
>>>
>>> Lib curl?
>>
>> This is not a browser. No, not every library which is able to send HTTP
>> requests and process the response is a "browser".
>>
>>
> Semantics.

No, facts. curl is not a browser. This has nothing to do with semantics.

--
Arno Welzel
https://arnowelzel.de

On 28/06/2022 11:59, The Natural Philosopher wrote:

<snip>
> I leave all that ego boosting semantics to computer scientists. I care
> simply that it works to do the intended job. I am just an engineer.

But not an engineer who recognises what he's done. That's not something
that inspires confidence in others.

John

On 28/06/2022 18:27, John Harris wrote:
> On 28/06/2022 11:59, The Natural Philosopher wrote:
>
>   <snip>
>> I leave all that ego boosting semantics to computer scientists. I care
>> simply that it works to do the intended job. I am just an engineer.
>
> But not an engineer who recognises what he's done. That's not something
> that inspires confidence in others.
>

Oh dear: another 'literalist'

I recognise that I have created code that meets the specification.
In the end it's all just bits in silicon.

>   John
>

--
In todays liberal progressive conflict-free education system, everyone
gets full Marx.

On Monday, June 27, 2022 at 2:32:04 AM UTC-5, Arno Welzel wrote:
> Michael Haufe (TNO):
> > On Sunday, June 26, 2022 at 12:02:27 PM UTC-5, Arno Welzel wrote:
> >> Michael Haufe (TNO):
> >
> >>> Applications that have an automated QA process use this often. You can test scenarios such as:
> >>>
> >>> "When the 'Clear Cart' button is clicked the associated users Shopping Cart is cleared"
> >
> >> I dont't understand why this requires a syncronous XMLHttpRequest. Test
> >> tools like Cypress can wait for events.
> >
> >>> You also have the use case of web scraping from batch scripts. Some CLIs don't support a proper DOM
> >>> such as PowerShell 7.
> >
> >> And web scraping needs XMLHttpRequest? Why?
> >
> > You seem to be drifting or making a point that wasn't expressed clearly.
> > Which question are you asking?
> My question was, why *synchronous* XHR is *required* for tests or web
> scraping. I have done testing with headless browsers myself a lot and
> never needed *synchronous* XHR ever.

Agreed

> Also "web scraping" means first of all just to send requests and wait
> for the result. There is no issue at all if this is done with
> asynchronous XHR.
> > If I'm in a browser (headless or otherwise) I can near trivially walk
> > the hyperlinks of the domain and collect information information such
> > as email addresses. It's just a DFS or BFS walk. The XHR object even
> > has the ability to provide a DOM as a result of a request directly
> > without parsing.
> And why does the XHR to be synchronous?

Right, I think we agree on all points. I don't see any use case for synchronous XHR here either. Walking a graph is parallelizable.