Analog screwed up their website...

[Don Y]

On 4/26/2022 7:47 AM, Dan Purgert wrote:

rbowman wrote:
On 04/25/2022 05:04 AM, Dan Purgert wrote:
It\'s like a resurgence of the flash-sites of the late \'90s / early \'00s
all over again.

This one may be here to stay. Angular, React, Vue, etc. Users have come
to expect single page applications and they take JavaScript -- a lot of
it. We\'re developing an Angular app and I don\'t even want to think about
how much JS.

Such a shame, isn\'t it?

The original vision didn\'t address the sort of interactions that users
(and providers) would want. So, the Web has just become a delivery
vehicle for virtual machine applets. In that sense, it is doing an
admirable job adjusting to constantly evolving interface demands.

[Imagine gopher(1) trying to do all this!]

Witness the number of cross-linked sites that most pages access just
to \"deliver\" a page\'s content (cuz they aren\'t *giving* you something
but, rather, trying to TAKE something FROM you!)

Oh well, The Web had a good run while it lasted. At least there\'s still
the rest of The Internet.

The bigger \"threat\" is the recognition that more folks consume content
using phones (tiny screens, piss poor user entry). It won\'t be long
before we find pages that really only make sense in a phone\'s aspect
ratio! (there is some skill required to build pages that can be equally
accessible in a wide range of form factors, etc.)

 

[rbowman]

On 04/26/2022 03:09 PM, Don Y wrote:

The bigger \"threat\" is the recognition that more folks consume content
using phones (tiny screens, piss poor user entry). It won\'t be long
before we find pages that really only make sense in a phone\'s aspect
ratio! (there is some skill required to build pages that can be equally
accessible in a wide range of form factors, etc.)

Even 7\" tablets are a challenge.

 

[rbowman]

On 04/26/2022 02:06 AM, Mike Monett wrote:

Firefox is not the only browser with problems on Canadian Tire. Seamonkey
screws up even more badly. It is completely unusable. I suspect it\'s not
the browser, but the way Canadian Tire writes their HTML.

Well, yeah...

https://www.seamonkey-project.org/

\"Under the hood, SeaMonkey uses much of the same Mozilla Firefox source
code which powers such products as Thunderbird. \"

It\'s what is under the hood that counts. Even Opera dropped Presto and
started using chromium code.

I use Brave, another child of chromium, on most of my machines. I have
it on this box but it is an older version. Updating is problematic since
it\'s OpenSUSE 13.2 from 2014. I missed leaping to Leap so at this point
it would be a clean install. The hardware is the same vintage. I\'m
definitely in the \'if it ain\'t broken\' camp.

Vivaldi is an interesting one. When Opera switched from Presto they also
dropped many of Opera\'s distinctive features upsetting the fans. Vivaldi
replicates those features despite also being a chromium derivative.

There\'s a whole cottage industry in cross-browser testing. Speaking as a
developer rather than a user, it\'s a pain. One bright development was
when MS redid Edge to use the chromium code. If there was one browser
that was guaranteed to break whatever you were trying to do, it was IE.

 

[Don Y]

On 4/26/2022 8:05 PM, rbowman wrote:

On 04/26/2022 03:09 PM, Don Y wrote:
The bigger \"threat\" is the recognition that more folks consume content
using phones (tiny screens, piss poor user entry). It won\'t be long
before we find pages that really only make sense in a phone\'s aspect
ratio! (there is some skill required to build pages that can be equally
accessible in a wide range of form factors, etc.)

Even 7\" tablets are a challenge.

Long ago, I made the decision that I wanted control over presentation
instead of flexibility in presentation. This imposes on the viewer/user
to have a suitable \"presentation device\". But, makes MY job *so* much
easier. I can concentrate on what I want to say/show instead of having
to anticipate how many different \"compromises\" will be imposed in the
rendering.

E.g., I often put animations in PDFs to better illustrate some concept
in an interactive manner. Hoping that the user can render that animation
on their \"browser\" just makes more work for me. Wanna view it on an
incompatible browser? Then you get a substandard document. Too bad,
so sad.

Likewise adding audio to a (typically) \"visual\" presentation. E.g.,
to illustrate how words like \"mash\" are pronounced differently in
different regions (to say something \"rhymes with bash\" is ambiguous)

 

[Mike Monett]

rbowman <bowman@montana.com> wrote:

On 04/26/2022 02:06 AM, Mike Monett wrote:
Firefox is not the only browser with problems on Canadian Tire.
Seamonkey screws up even more badly. It is completely unusable. I
suspect it\'s not the browser, but the way Canadian Tire writes their
HTML.

Well, yeah...

https://www.seamonkey-project.org/

\"Under the hood, SeaMonkey uses much of the same Mozilla Firefox source
code which powers such products as Thunderbird. \"

It\'s what is under the hood that counts. Even Opera dropped Presto and
started using chromium code.

I use Brave, another child of chromium, on most of my machines. I have
it on this box but it is an older version. Updating is problematic since
it\'s OpenSUSE 13.2 from 2014. I missed leaping to Leap so at this point
it would be a clean install. The hardware is the same vintage. I\'m
definitely in the \'if it ain\'t broken\' camp.

Vivaldi is an interesting one. When Opera switched from Presto they also
dropped many of Opera\'s distinctive features upsetting the fans. Vivaldi
replicates those features despite also being a chromium derivative.

There\'s a whole cottage industry in cross-browser testing. Speaking as a
developer rather than a user, it\'s a pain. One bright development was
when MS redid Edge to use the chromium code. If there was one browser
that was guaranteed to break whatever you were trying to do, it was IE.

LOL!

Seamonkey may share some source with Thunderbird, but the browser wrecks
Canadian Tire in a completely different way.

It also does not seem to be able to use Firefox extensions, such as
AdBlock Plus, Audio Equalizer, I Don\'t Care About Cookies, and Javascript
Toggle On And Off. The last one is especially useful to block logon
requirements on many web pages. You just click on a small icon in the
upper righ corner of the screen. The Seamonkey version is extremely
cumbersome:

\"Edit -> Preferences -> Advanced -> Scripts & Plug-ins -> Enable
JavaScript for -> Navigator\"

However, it may be blocked by NoScript

SeaMonkey might as well be a completely different browser.

I actually never use SeaMonkey for browsing. I only need it when receiving
an email that I must respond to that uses HTML. My regular email client is
Pimmy 3.5, which is plain ASCII text only. It does not understand HTML,
and is immune to <IFRAME> attacks.

It also handles an unlimited number of email addresses, which I use to
eliminate spam. If a site begins sending me spam, I merely delete it from
my list of email addresses. You can generate your own list at

http://www.e4ward.com/

I rarely get spam anymore. I once wrote my own spam filtering program
using Bayesian filtering, but it was simply too much work to keep up with
changes in spam messages and new techniques. The combination of Pimmy and
e4ward is much simpler and permanent.




--
MRM

 

[Mike Monett]

Forget all my rants about SeaMonkey. I just deleted it.

I found I have another email client that handles HTML. It is Opera Mail V1.0
and is on another VirtualBox operating system. It works very well and is easy
to use.

I love VirtualBox. I simply could not survive without it.



--
MRM

 

[Jan Panteltje]

On a sunny day (Wed, 27 Apr 2022 05:03:40 -0000 (UTC)) it happened Mike Monett
<spamme@not.com> wrote in <XnsAE86ACBC856Didtokenpost@144.76.35.252>:

Seamonkey may share some source with Thunderbird, but the browser wrecks
Canadian Tire in a completely different way.

It also does not seem to be able to use Firefox extensions, such as
AdBlock Plus

FYI
I have been running adblock plus for 10 years or more on seamonkey
its a great browser, but no raspi version yet I know about.

Audio Equalizer,

Wrote my own audio equalizer:
http://panteltje.com/panteltje/xpequ/index.html
standalone no need for browsers



I Don\'t Care About Cookies, and Javascript

Toggle On And Off. The last one is especially useful to block logon
requirements on many web pages. You just click on a small icon in the
upper righ corner of the screen. The Seamonkey version is extremely
cumbersome:

\"Edit -> Preferences -> Advanced -> Scripts & Plug-ins -> Enable
JavaScript for -> Navigator\"

However, it may be blocked by NoScript

SeaMonkey might as well be a completely different browser.

I actually never use SeaMonkey for browsing. I only need it when receiving
an email that I must respond to that uses HTML. My regular email client is
Pimmy 3.5, which is plain ASCII text only. It does not understand HTML,
and is immune to <IFRAME> attacks.

fetchmail here to get email, been using it since 1998
together with pine to read it.

It also handles an unlimited number of email addresses, which I use to
eliminate spam. If a site begins sending me spam, I merely delete it from
my list of email addresses. You can generate your own list at

http://www.e4ward.com/

I rarely get spam anymore. I once wrote my own spam filtering program
using Bayesian filtering, but it was simply too much work to keep up with
changes in spam messages and new techniques. The combination of Pimmy and
e4ward is much simpler and permanent.

I like \'spam\' or rather advertizing, shows my system is still working
I have near unlimited email addresses...
I assign every company its own, so if \'spam\' comes in I know who it was
and either unlist or warn them they have been hacked.

It is good in tracking the bad guys too as recently shown.

All my editing and coding is done with \'joe\' text editor.

An this is posted with NewsFleX ported to and running on a Raspberry4 8 GB.
Written the code so full control
http://panteltje.com/panteltje/xpequ/index.html
Do any of you guys ever publish any code>?

Chromium works OK on this very small computah too.

 

[Jan Panteltje]

On a sunny day (Tue, 26 Apr 2022 14:09:25 -0700) it happened Don Y
<blockedofcourse@foo.invalid> wrote in <t49n2e$9p3$1@dont-email.me>:

The bigger \"threat\" is the recognition that more folks consume content
using phones (tiny screens, piss poor user entry). It won\'t be long
before we find pages that really only make sense in a phone\'s aspect
ratio! (there is some skill required to build pages that can be equally
accessible in a wide range of form factors, etc.)

I dunno, I prefer the phone format as info in text form is mostly all you need.
examples:
https://www.ard-text.de/mobil/101
for the news in (German)
or
https://www.tvguide.co.uk/mobile/channellisting.asp?ch=1243#582517827
for Smithsonian program listing for TV

You can always use ctlr + or ctrl - or ctrl 0 in your browser to enlarge it etc
a decent browser will remember the enlargement settings for each site/.

No ads.
Basic HTML.
I build my own website with basic HTML:
panteltje.com
No advertising and no java.

That stuff is not normally needed, one can always make a youtube video
if more info is needed.
Interactive? Download and compile my code

Have a local copy of the site running on Apache server,
I test new entries locally first, then it goes to the site.

 

[Dan Purgert]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Jan Panteltje wrote:

[...]
Do any of you guys ever publish any code>?

Every once in a while, when I write something that someone might find
useful (or fun...). Granted I\'ve been moving away from github to a
self-hosted gitlab in the last year or two ...


-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE3asj+xn6fYUcweBnbWVw5UznKGAFAmJpEIAACgkQbWVw5Uzn
KGAH1A/+OcidBwxRvOZf7HnNwn6iUEbijSKCK5igaxI4XIex/K+8UZJzHOHxM9bO
LkSujMIw1oeZVXvypDD/N2LvGCk4szRu9NHn10NuhPKOR2kZq4me12H91gBH3VKg
Y9h1oTvE2uzCPnB4O0vkfxiLGJhFBj28baVGHTfhWXSdk8B7J6zAecd+csigygqG
nQ/6l3J//HANqtCQPVqxYLal9altplMoj8z1LHUqG+GXmY6gGFR6a7aLar0pM2Of
zihVBfjYDEgzfPJ+VH0EQwKEEAtLQ6MekxV196jPyVzNSscC5hsMzHAE2ykwgilK
TvZpcmicrZLcLm4Y0cEMGbDz3wJWxjkH70aweB07acmmcxrUASn9Q/g3JtgbBm5w
CYeFUpa3vrYPbeFPD+8SxA/KIgvn6d2/o7Wi2/T75/YKzco0z4nQM9sJkJBDzx2g
mz9Pyqemrk2sq0MFk/rdvZIyTbe4mgGpgIbckFtie5tocR8HaV+IiQdIRwoM1UnP
9bp8VRlItTsZqFb4KcktEtzSleewVSlJokk88tEP6ExXSEXRs1I2LUUV3sqEML4h
gq82OvabLh4TEbY6shvQ9nF/8A6aUjDa7Hb9WWZXVwhD5JjDL1E4ex+kbDoaN6q9
yzUjJNaLNfE/YiTz4izD/oAmhO8sUghNYbQxwzU9/qlD+p5efe4=
=KJU6
-----END PGP SIGNATURE-----

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

 

[rbowman]

On 04/26/2022 11:03 PM, Mike Monett wrote:

Seamonkey may share some source with Thunderbird, but the browser wrecks
Canadian Tire in a completely different way.

There\'s always room for creativity. Dealing with browsers is like
playing whack-a-mole. A long discussion during our
Monday meeting concerned cut\'n\'paste and the relationship between the
browser and the Windows clipboard. FF is different to the chromium based
browsers, so how to fix a FF bug without creating a further cascade of
bugs? It\'s never the big things just ongoing annoyances.

We\'re developing a product that has to be presentable. Canadian Tire is
selling tools and tires, not a web application so they can be a little
more cavalier. Their customers grumble a little and use another browser.
Ours grumble a lot and refuse to switch. In one case it was because
another application didn\'t work except with xxxxx browser.

 

[rbowman]

On 04/26/2022 09:59 PM, Don Y wrote:

n 4/26/2022 8:05 PM, rbowman wrote:
On 04/26/2022 03:09 PM, Don Y wrote:
The bigger \"threat\" is the recognition that more folks consume content
using phones (tiny screens, piss poor user entry). It won\'t be long
before we find pages that really only make sense in a phone\'s aspect
ratio! (there is some skill required to build pages that can be equally
accessible in a wide range of form factors, etc.)

Even 7\" tablets are a challenge.

Long ago, I made the decision that I wanted control over presentation
instead of flexibility in presentation. This imposes on the viewer/user
to have a suitable \"presentation device\". But, makes MY job *so* much
easier. I can concentrate on what I want to say/show instead of having
to anticipate how many different \"compromises\" will be imposed in the
rendering.

I can only dream about being able to do that.

 

[Jeroen Belleman]

On 2022-04-27 16:23, rbowman wrote:

On 04/26/2022 11:03 PM, Mike Monett wrote:
Seamonkey may share some source with Thunderbird, but the browser
wrecks Canadian Tire in a completely different way.

There\'s always room for creativity. Dealing with browsers is like
playing whack-a-mole. [...]

Come on, it isn\'t that hard to make something that works in any
browser. Of course, you have to avoid using all these snazzy
features that web development package writers are so fond of.
That shouldn\'t really be a problem, because most of those features
are irritating anyway. We don\'t need animations, we don\'t want
complete remakes of the user interface, we don\'t want JavaScript
where straight HTML will do. Simple is best.

Jeroen (I hate spinners) Belleman

 

[Don Y]

On 4/27/2022 7:49 AM, Jeroen Belleman wrote:

On 2022-04-27 16:23, rbowman wrote:
On 04/26/2022 11:03 PM, Mike Monett wrote:
Seamonkey may share some source with Thunderbird, but the browser
wrecks Canadian Tire in a completely different way.

There\'s always room for creativity. Dealing with browsers is like
playing whack-a-mole. [...]

Come on, it isn\'t that hard to make something that works in any
browser. Of course, you have to avoid using all these snazzy
features that web development package writers are so fond of.
That shouldn\'t really be a problem, because most of those features
are irritating anyway. We don\'t need animations, we don\'t want
complete remakes of the user interface, we don\'t want JavaScript
where straight HTML will do. Simple is best.

\"Everything should be made as simple as possible, but not simpler.\"

The problem is when \"simplest\" exceeds the capabilities of \"straight HTML\".

You don\'t want to have to take a round-trip to the server each time a user
changes a field/control on a page/form. So, you push that logic to the
client side -- script. It\'s nice to be able to do an INTERACTIVE
search on Digikey\'s site -- instead of having to make selections and
take another trip to the server to see how those selections affect your
NEW choices. (I suspect you\'d quickly tire of having to RESUBMIT each time
you were unhappy with the choices left to you from some previous choice made)

The problem is that applications are trying to use the browser FOR the UI.
And, in order to get the responsiveness that users expect/demand/require,
that means doing local, client-side processing.

Sadly, the automatic code generators seem to create lots of cruft just
to get some \"basic functionality\" in place. (and, you wouldn\'t want to
pay someone to hand-craft these sorts of VERY VISIBLE interfaces)

 

[Don Y]

On 4/27/2022 7:26 AM, rbowman wrote:

On 04/26/2022 09:59 PM, Don Y wrote:
n 4/26/2022 8:05 PM, rbowman wrote:
On 04/26/2022 03:09 PM, Don Y wrote:
The bigger \"threat\" is the recognition that more folks consume content
using phones (tiny screens, piss poor user entry). It won\'t be long
before we find pages that really only make sense in a phone\'s aspect
ratio! (there is some skill required to build pages that can be equally
accessible in a wide range of form factors, etc.)

Even 7\" tablets are a challenge.

Long ago, I made the decision that I wanted control over presentation
instead of flexibility in presentation. This imposes on the viewer/user
to have a suitable \"presentation device\". But, makes MY job *so* much
easier. I can concentrate on what I want to say/show instead of having
to anticipate how many different \"compromises\" will be imposed in the
rendering.

I can only dream about being able to do that.

Your current dream is likely a nightmare! :>

My goal is to convey information to the reader/viewer. As much information
as possible in as expressive a form as possible. Note that I\'m creating
references, not transient \"interactions\".

I figure the reader should be willing to make an effort to *consume* that
information. If he wants to be lazy and opt for some ineffective mechanism,
then HE should bear the cost of that poor choice.

Good luck reading that schematic on your iPhone! Or, perusing that long,
multicolumn table. :>

 

[rbowman]

On 04/27/2022 08:49 AM, Jeroen Belleman wrote:

On 2022-04-27 16:23, rbowman wrote:
On 04/26/2022 11:03 PM, Mike Monett wrote:
Seamonkey may share some source with Thunderbird, but the browser
wrecks Canadian Tire in a completely different way.

There\'s always room for creativity. Dealing with browsers is like
playing whack-a-mole. [...]

Come on, it isn\'t that hard to make something that works in any
browser. Of course, you have to avoid using all these snazzy
features that web development package writers are so fond of.
That shouldn\'t really be a problem, because most of those features
are irritating anyway. We don\'t need animations, we don\'t want
complete remakes of the user interface, we don\'t want JavaScript
where straight HTML will do. Simple is best.

Jeroen (I hate spinners) Belleman

All depends on what you\'re doing. If you\'re building a browser based
highly interactive computer aided dispatch system to parallel a legacy
desktop suite of applications you\'re not going to get there with static
html pages.

 

[Don Y]

On 4/27/2022 8:10 PM, rbowman wrote:

All depends on what you\'re doing. If you\'re building a browser based highly
interactive computer aided dispatch system to parallel a legacy desktop suite
of applications you\'re not going to get there with static html pages.

But what\'s the motivation for a browser-based solution?
Are you trying to have a \"no install\" application (which
makes it immediately available to EVERY seat)?
Or, streamline maintenance (server-side updates)?
Or...?

Is this just another repeat of the centralized/distributed cycle
(mainframe->workstations->server/clients-> ...)

 

[rbowman]

On 04/27/2022 09:48 PM, Don Y wrote:

On 4/27/2022 8:10 PM, rbowman wrote:
All depends on what you\'re doing. If you\'re building a browser based
highly interactive computer aided dispatch system to parallel a legacy
desktop suite of applications you\'re not going to get there with
static html pages.

But what\'s the motivation for a browser-based solution?
Are you trying to have a \"no install\" application (which
makes it immediately available to EVERY seat)?
Or, streamline maintenance (server-side updates)?
Or...?\'

All of the above... In the last few years I\'ve been seeing a lot of
RFP\'s calling for zero footprint solutions. Some of that is justified
paranoia about hacking. They don\'t advertise but an embarrassing number
of sites have been pwned. Zero footprint means you can lock the
workstations down tight and not let the users wander off to watch cat
videos or whatever.

They\'ve backed off the cloud based fad. AWS has dumped often enough to
take the shine off that. Losing Twitter for a couple of hours, no big
deal. Losing your emergency response dispatch system is something else.
Technically you\'re building a private cloud on premises and assuming the
costs of buying and maintaining HA servers. That is the selling point of
Azure/AWS etc -- let us worry about all that -- which is fine until it
isn\'t. The other problem with the cloud is sensitive information. There
are providers that offer secure installations with fully vetted
personnel but that adds cost.

If you\'ve looked in a police car, fire truck, or ambulance lately they
are fully wired. Have to physically update a couple of hundred mobile
laptops is a problem. Even updating desktops in the dispatch center can
be tricky. You try to pick a quiet time to take stations offline one by
one and hope there isn\'t a mass casualty incident.

Is this just another repeat of the centralized/distributed cycle
(mainframe->workstations->server/clients-> ...)

Most certainly. IBM\'s revenge. Money is always an issue and with a thin
client you don\'t have to go overboard on the computer and can put the
money into big 4K monitors.

https://www.motorolasolutions.com/en_us/products/command-center-software/voice-and-computer-aided-dispatch.html

Not our system but scroll down a little and that\'s a typical dispatch
center. Those people love their monitors. The more the merrier.

Who knows what the next iteration will bring?

 

[Mike Monett]

rbowman <bowman@montana.com> wrote:

On 04/27/2022 08:49 AM, Jeroen Belleman wrote:
On 2022-04-27 16:23, rbowman wrote:
On 04/26/2022 11:03 PM, Mike Monett wrote:
Seamonkey may share some source with Thunderbird, but the browser
wrecks Canadian Tire in a completely different way.

There\'s always room for creativity. Dealing with browsers is like
playing whack-a-mole. [...]

Come on, it isn\'t that hard to make something that works in any
browser. Of course, you have to avoid using all these snazzy
features that web development package writers are so fond of.
That shouldn\'t really be a problem, because most of those features
are irritating anyway. We don\'t need animations, we don\'t want
complete remakes of the user interface, we don\'t want JavaScript
where straight HTML will do. Simple is best.

Jeroen (I hate spinners) Belleman


All depends on what you\'re doing. If you\'re building a browser based
highly interactive computer aided dispatch system to parallel a legacy
desktop suite of applications you\'re not going to get there with static
html pages.

What has that got to do with a simple parts ordering page?

RockAuto handles millions of parts with ordinary browsers:

https://www.rockauto.com/

Amazon handles millions of parts with ordinary browsers:

https://www.amazon.com

Instacart handles lots of items with ordinary browsers:

https://www.instacart.com

Youtube handles billions of videos with ordinary browsers:

https://www.youtube.com/

A huge part of business runs with ordinary browsers.

Why does Canadian Tire require one specific browser?




MRM

 

[Don Y]

On 4/27/2022 10:28 PM, rbowman wrote:

On 04/27/2022 09:48 PM, Don Y wrote:
On 4/27/2022 8:10 PM, rbowman wrote:

But what\'s the motivation for a browser-based solution?
Are you trying to have a \"no install\" application (which
makes it immediately available to EVERY seat)?
Or, streamline maintenance (server-side updates)?
Or...?\'

All of the above... In the last few years I\'ve been seeing a lot of RFP\'s
calling for zero footprint solutions. Some of that is justified paranoia about
hacking. They don\'t advertise but an embarrassing number of sites have been
pwned. Zero footprint means you can lock the workstations down tight and not
let the users wander off to watch cat videos or whatever.

So, you\'re using the browser to give you the functionality of an \"X Terminal\"?
But, you\'re still letting that build on a COTS OS (e.g., windows)? Does the
user *need* the \"generic PC\" to be present IN ADDITION to the browser? I.e.,
why not replace the OS and browser and make a dedicated appliance (with
deliberately limited functionality)?

Or, do you want MS to deal with the \"multiple vendor support\" issues (so YOU
don\'t have to develop network and video drivers for an unlimited number of
potential hardware configurations)?

> They\'ve backed off the cloud based fad. AWS has dumped often enough to take the

Hmmmm... that\'s an interesting observation (the whole \"cloud\" idea struck me
as seriously flawed)

shine off that. Losing Twitter for a couple of hours, no big deal. Losing your
emergency response dispatch system is something else. Technically you\'re
building a private cloud on premises and assuming the costs of buying and
maintaining HA servers.

So, do you deploy the server-side code on commodity hardware? Or, \"certified\"
(commodity) hardware -- so you have some control over that performance?

If \"local\", then the trip to the server isn\'t as costly. So, why not move
everything into the server (eliminating script altogether)? Or, does that
solution not scale adequately (i.e., you\'re relying on the clients to
effectively share some of the computational load)?

That is the selling point of Azure/AWS etc -- let us
worry about all that -- which is fine until it isn\'t. The other problem with
the cloud is sensitive information. There are providers that offer secure
installations with fully vetted personnel but that adds cost.

I assume you aren\'t deploying personnel to each site but, rather, doing remote
administration? Presumably, you\'ve got that locked down tight so *you* aren\'t
the attack vector? (all traffic in an encrypted tunnel?)

If you\'ve looked in a police car, fire truck, or ambulance lately they are
fully wired. Have to physically update a couple of hundred mobile laptops is a
problem. Even updating desktops in the dispatch center can be tricky. You try
to pick a quiet time to take stations offline one by one and hope there isn\'t a
mass casualty incident.

But you\'re NOT updating those things, right? That\'s the whole point of
pushing script into the clients \"on demand\"...

Instead of something truly minimalist (like a Sun Ray), you\'re relying
on the browser to give you \"advanced primitives\" that you can invoke,
via script?

But, by doing so, you are now at the mercy of the browser(s) that you
want (?) to support.

Is this just another repeat of the centralized/distributed cycle
(mainframe->workstations->server/clients-> ...)

Most certainly. IBM\'s revenge. Money is always an issue and with a thin client
you don\'t have to go overboard on the computer and can put the money into big
4K monitors.

Yeah, I fully embraced the thin client ideology many years ago. It made
maintenance SO much easier! (By contrast, my workstations incur LOTS of
maintenance). My current project relies completely on a bare bones
client -- more like the Sun Rays than a browser or even an X Terminal
(so, NEVER a need to update the client!)

Not our system but scroll down a little and that\'s a typical dispatch center.
Those people love their monitors. The more the merrier.

Yeah, it\'s addictive. I run 5-6Kx2K on my workstations. The limit being how
much I can take in with my eyes WITHOUT moving my head (the \"tennis match\"
syndrome gets old, quick!)

> Who knows what the next iteration will bring?

Someone will invariably lament that the latency is too great for games (or
some other ENTERTAINMENT-related activity) and push to put more \"programmable
features\" in the UI.

Until that bloats to the point of a real workstation -- which will restart the
cycle....

Enough is never enough -- esp if you can rationalize someone ELSE paying for
it!

 

[rbowman]

On 04/27/2022 11:32 PM, Mike Monett wrote:
> Why does Canadian Tire require one specific browser?

Simply put, because they don\'t care or the website was developed by
someone\'s cousin\'s kid. Looking at their page source they\'re not doing
anything fancy.

There might be a clue with the various references to apple. It may work
like a charm with Safari.