[Info-vax] VMS Server and WebApp future and People Power

[Richard Maher]

On 19-Feb-16 10:02 PM, Stephen Hoffman wrote:
> On 2016-02-19 02:07:20 +0000, maherrj at googlemail.com said:
>
>> I beg all of you who are interested in the growth of HTML5
>> functionality and the future of browser-hosted web-apps to read the
>> following: -
> ....
>> The currently proposed geofencing design current ignores the need for
>> a holistic server-based solution.  That server will be JAVA, C#, or
>> VMS 3GL?
>
> You forgot to include artisanal and crafted from the finest organic
> bits, there.
>
> I have no idea what you're on about here either, Richard.

When have you ever :-)
>
> Unless you're thinking of running location or other services in the
> background on a server?

Sort of. The geofence(s) location and area is maintained by the Server! 
The client javascript in the Service Worker (SW = Battery saving 
construct) will XHR the last location to the server. Thus the server 
knows who has to be PUSHed.

>  I'm guessing that some folks on this committee — not really
> wanting to wade through a couple of large piles of discussions
> previously referenced, either — are looking at the server performing
> pushes to either retrieve the data from the client, or to establish a
> geofence to trigger some activity on the client, or maybe the client
> sends a push back to the server when the geofence is exceeded, with the
> Javascript running in the background?

Yes.

While you're here can you tell me if you think these comments of mine 
may have been counter-productive: -

]]]]]]]]
Look, I'm not paranoid enough to suggest that W3C members are on the 
take from the Native App providers but, Service Worker developers are 
simply being obtuse if they continue to deny the requirements for 
location tracking and not just a hamstrung, debilitated geoFence API. 
The requestWakeLock() method has it's uses for those who don't care 
about battery life. User/device tracking Apps is not one of them.
[[[[[[[[

and

[[[[[[[[
Regarding the less than enthusiastic response here and at W3C however, I 
put it down to the emotional, financial, and temporal investment that 
has already gone into the lemon that is https://www.w3.org/TR/geofencing/

I have stuck my head into the W3C pram and revealed to the parents that 
their GeoFence baby is simply butt ugly! What's more, outside of the 
rarefied atmosphere of "F2F time at TPAC" and the ski slopes of Sapporo, 
*EVERYONE* knows the GeoFence API has no clothes. Chrome has long ago 
aborted its implementation. It's a shame that the "plenary" sessions 
don't include WebApp development grunts as the resulting standards would 
be far less limited in their application.
]]]]]]]]


>
> Sending nasynchronous otifications to a server is comparatively easy,
> too.   Most servers being far less communications- and
> resource-constrained than mobile, battery-powered clients, after all.

Yes, yes, YES! That's it! Why are those dickheads devolving the locgi 
and processing to a myopic client???
>
>> I understand the concerns about privacy and battery-life and am more
>> than happy to address them in a lively debate.
>
> I too understand the concerns, being quite dependent on mobile devices,
> and do use location services, geofences and push.   Location services
> and geofencing are (obviously) already available on mobile devices,
> through native apps, and those can (obviously) be backgrounded.  Those
> links appear to be the HTML5 committee sorting out how to add those same
> capabilities into web browser clients, allowing those capabilities in
> the background.

They're floundering :-( Don't trust me just look.

>
> Not clear what any of that has to do particularly with OpenVMS,

Just because it is a future server platform. (And I can troll here :-)

> nor why
> I'd particularly want to go engage a W3C committee on this topic.

Because you have a way of researching and wording things effectively.

> They'll either sort this out, or they won't.  I can get what I need here
> with a native client, though that approach is clearly more of a hassle
> than a Javascript web client.   Or I can get what I want here with JSON
> or some other web API on the server, for that matter.

Yep, it's all me, me, me with you isn't it?

Thanks again.