Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Lawrence D'Oliveiro <ldo@nz.invalid>
Newsgroups: comp.os.vms
Subject: Re: Transparent task to task
Date: Wed, 4 Jun 2025 00:26:31 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <101o3rn$br8d$7@dont-email.me>
References: <101lah0$3iet6$2@dont-email.me> <101ms82$v2r$1@dont-email.me>
	<101n40p$34un$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 04 Jun 2025 02:26:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="07eb04b10edcc155499fc6f2f949ef2b";
	logging-data="388365"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18N9YfpmiXsPFOSdSqm6CcE"
User-Agent: Pan/0.162 (Pokrosvk)
Cancel-Lock: sha1:m19UzC9egPjdd0aUv92fCk3c/Fw=

On Tue, 3 Jun 2025 11:23:06 -0400, Arne Vajhøj wrote:

> It is true that a HTTP GET can result in different actions: web server
> returning static HTML, web server running code that produce dynamic HTML
> without changing anything, web server running code that produce dynamic
> HTML and do change something.

Ah, now you’re getting into something called “REST”, where HTTP is being 
used essentially as a sort of RPC mechanism.

This involves the addition of more commands besides GET and POST: you also 
have PUT and DELETE (and possibly others as well). GET is not supposed to 
cause any (user-visible) state changes; it’s only supposed to return info. 
As I understand it, POST is supposed to be the mechanism for creating 
objects, PUT is supposed to be used for changing the state of objects, and 
DELETE is to be used for deleting objects.

But of course there is no way of firmly enforcing semantics like this.

> But not sure that I see the TYPE command being similar to a HTTP GET.

As pointed out already, it’s not the fault of the TYPE command, it’s the 
fault of the underlying comms architecture that allows for this behaviour. 
It works with any other command that can open an arbitrary user-specified 
file through the same API layer (i.e. RMS).