[Info-vax] First ship poll: When will the first native x86-64 compilers ship ?

Richard Maher maher_rjSPAMLESS at hotmail.com
Sat Apr 16 23:36:37 EDT 2022


On 17/04/2022 10:04 am, Dave Froble wrote:
> On 4/16/2022 7:00 PM, Craig A. Berry wrote:
>> On 4/16/22 5:25 PM, Dave Froble wrote:
>>> On 4/16/2022 6:14 PM, Arne Vajhøj wrote:
>>>> On 4/16/2022 11:02 AM, Jan-Erik Söderholm wrote:
>>>>> Den 2022-04-16 kl. 13:28, skrev Bill Gunshannon:
>>>>>> On 4/15/22 22:10, Dave Froble wrote:
>>>>>>> On 4/15/2022 7:25 PM, Arne Vajhøj wrote:
>>>>>>>> Cobol, Basic, Pascal, C etc. is just not the optimal language
>>>>>>>> for writing a new web service.
>>>>>>>>
>>>>>>>> Not on any platform.
>>>>>>>
>>>>>>> Really depends on the web service, doesn't it?
>>>>>
>>>>> And on the *definition* of "web services".
>>>>
>>>> There may not be a formal definition, but most developers have
>>>> a common understanding what such a thing is.
>>>>
>>>> Something like: a service intended to be used by client applications
>>>> based on web protocols typical XML/HTTP(S) or JSON/HTTP(S).
>>>>
>>>> Arne
>>>>
>>>
>>> Well, there you go again, refining the definition to match your 
>>> claims.  Of
>>> course that makes you right.
>>>
>>> How about anything that offers some service that might be needed over 
>>> the
>>> internet?
>>
>> Nope.  That would be an internet service.  A web service uses some
>> version of the HTTP protocol.  While that doesn't necessarily imply
>> REST, the simplicity of REST has made web services largely eclipse older
>> client-server protocols such as SOAP or Java RMI.
> 
> Having looked at REST, I find it as difficult and performance robbing as 
> the "rest" (no pun intended) of the "standard" protocols.  We have done 
> some testing.  We find that using sockets with no additional overhead 
> has given us the best performance and the least overhead and the 
> simplest programming.
> 

*** On "performance" note that Tier3's socket multiplexing via JAVA 
Applet STATIC variables predated HTTP 1.1 and Google's multiplexing. 
(Should've had a patent :-( )

But everyone agrees *no one* would start today with HTTP as the 
client/server middleware protocol of choice! It just happened and we are 
where we are.

When it comes to RESTful the main problem is sessions, by definition, 
are out of scope. Then you get your regular Java wankers telling you 
JWTs are the answer except they're a huge security and performance risk. 
But they are popular 'cos all the session data is in the JWT cookie but 
can't be cancelled and leads to same cognoscente deciding to revalidate 
every 10secs :-(

Which delivers us nicely to FIDO2 passwordless(ish) authentication. VMS 
must support this by being a validator.

But that's just authentication, what about authorization? Well that's 
where VMS has to support REDis cache, or whatever Oracle has.

Lots to do eh?



More information about the Info-vax mailing list