Dioscuri, another application layer protocol

Dioscuri is a protocol intended to supplement Gemini for doing things like
uploading files, performing remote actions, and running an application
server.  It is the POST to Gemini's GET.  Dioscuri servers will run on a
different port altogether, so that they do not interfere with Gemini
servers.  Dioscuri, unlike Gemini, absolutely *requires* the use of client
certificates.

Great thanks to the members of irc://tilde.chat/gemini, especially lukee
and aravk.

The name "Dioscuri" is the Latinized spelling of the Greek name for the
Heavenly Twins, Castor and Pollux/Polydeukes, who were called Gemini in
Latin; the constellation is named after them.  I say dee-OH-skoo-ree, but
Greeks, classicists, and others should feel free to pronounce the name
their way.

=======

A Dioscuri request starts out with the client sending a single line,
<URL><SP><MEDIA-TYPE><CR><LF>.  This indicates that a body follows which
should be interpreted according to the media type.  For example, "gemini://
example.org/foo text/gemini\r\n" means that the Dioscuri server should do
something with the following body, which is of type text/gemini.  Exactly
what happens depends on the server and the URL.  For example, it might
replace the contents of "foo" with the uploaded body.  Alternatively,
"gemini://example.org/do/this text/javascript\r\n" might cause the
JavaScript in the uploaded body to be executed on the server.

As a special case, a client can send a Dioscuri header without a media type
or separating space, in which case no request body is allowed or expected.
This can be used if the contents of the URL are sufficient to tell the
server what to do.

=======

When Dioscuri has received the header and body, then it does whatever it
does and returns a regular Gemini header with some extensions.  If the
server is going to be conversational, it will process the uploaded body
with whatever semantics it assigns to it and then send a regular Gemini
response header.  For example, an application server might be sent a
header "<URL> application/json\r\n" followed by a JSON value, compute
something, and return "20 application/json\r\n" followed by the computed
JSON value.

If the server has nothing to send to the client, as in the case of an
upload, it can respond with "20\r\n", which means that there is no response
body.

=======

By mutual agreement between the client and the server, the server may
return "70 <URL>\r\n" not  followed by a body.  This code means that the
request has succeeded, but rather than the server sending a response body
in the same TCP connection, the response body can be found at <URL>.

A use case for this is that the client wishes to add a new file to a
container (directory or whatever) in the server but leaves it up to the
server to choose the new URL according to some algorithm (random,
timestamp, etc.)  So a request of "<container-URL> text/gemini\r\n"
followed by the body would in such a case respond "60 <object-URL>\r\n",
meaning that the new resource can be found at <object-URL>.

All other 2-digit response codes have the same meaning in Dioscuri as in
Germini.  The reason for not using the 30 code in place of 60 is that 30
would mean "redirect the request", as for all other cases of 30, whereas 60
means "the response can be found here."  I thought of using 21, but that
would make the second status digit an essential part of the protocol.  Note
that like 2x, 6x is considered a success.

=======

Finally, an implementation note: the TCP library used to implement Dioscuri
clients must be able to separately close the input and the output sides of
the TCP connection to the server.  So in the application server discussed
above, the client closes the output side of its socket when it has sent the
body, and the server receives EOF when it attempts to read more body.
However,  the input side on the client must remain open so that the
server's response can be read.

Comments?



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
And it was said that ever after, if any man looked in that Stone,
unless he had a great strength of will to turn it to other purpose,
he saw only two aged hands withering in flame.   --"The Pyre of Denethor"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200927/1020
e3cd/attachment.htm>

John Cowan <cowan at ccil.org> writes:

> A Dioscuri request starts out with the client sending a single line,
> <URL><SP><MEDIA-TYPE><CR><LF>.  This indicates that a body follows which
> should be interpreted according to the media type.  For example, "gemini://
> example.org/foo text/gemini\r\n" means that the Dioscuri server should do
> something with the following body, which is of type text/gemini.  Exactly
> what happens depends on the server and the URL.  For example, it might
> replace the contents of "foo" with the uploaded body.  Alternatively,
> "gemini://example.org/do/this text/javascript\r\n" might cause the
> JavaScript in the uploaded body to be executed on the server.

Does Dioscuri have the same line-length limits as Gemini?

>
> By mutual agreement between the client and the server, the server may
> return "70 <URL>\r\n" not  followed by a body.  This code means that the
> request has succeeded, but rather than the server sending a response body
> in the same TCP connection, the response body can be found at <URL>.
>
> A use case for this is that the client wishes to add a new file to a
> container (directory or whatever) in the server but leaves it up to the
> server to choose the new URL according to some algorithm (random,
> timestamp, etc.)  So a request of "<container-URL> text/gemini\r\n"
> followed by the body would in such a case respond "60 <object-URL>\r\n",
> meaning that the new resource can be found at <object-URL>.
>

Do you mean "70" here instead of "60"?

>
> Finally, an implementation note: the TCP library used to implement Dioscuri
> clients must be able to separately close the input and the output sides of
> the TCP connection to the server.  So in the application server discussed
> above, the client closes the output side of its socket when it has sent the
> body, and the server receives EOF when it attempts to read more body.
> However,  the input side on the client must remain open so that the
> server's response can be read.

Are there any limits on payload length from the client? Are there any
plans for the client to indicate to the server the length of the
payload? What happens if the server encounters a fault while reading in
the entire client payload?

Is there any guidance on timeouts? Should implementors assume that
timeouts are quick and the server should hangup quickly if nothing is
found on the client's send stream, or is this application dependent so
that it's up to the server/endpoint to determine timeouts (e.g. for a
streaming application)? My worry is that opening connections to the
server and keeping the server send connection open can quickly exhaust
the number of sockets/fds the server has available.

- meff

Complexity inside the server I don't particularly fear.
My biggest fear for Gemini has been a proliferation of protocols.
"Protocols" defined loosely, not just as foo:// but as whenever a
computer asks something of another and expects a reply in a particular
format.

That fear was behind my hesitiation re codifying behavior in the alt
text strings earlier.

As for whatever a server does on its own, I leave great allowance.
Requests being files in a file system or routes in an MVC. But when two
computers talk to each other, that's the point when two giant spinning
spheres of grinding greebles speeding through space need to make
contact. Need to get on the same page on what they are doing.

We'll look back years from now when gemspace collective standards have a
complexity that overshadows that of the W3C specifications, and maybe
we'll recognize that this moment, this post was the Rubicon. Maybe we'll
think that the Pandora lid was already peeked through to the point of no
salvation, since an arbitrary sequence of GET requests could become a
protocol.

Even if the future disastrous level of complexity is inevitable, I'm not
convinced it needs to be parallel. When we are proposing protocols that
could already be done through existing standards (such as https) I ask
that there is very good reason why.

"Oh, it's chill, any particular client and any particular server can use
this for ANY semantics" only makes me more concerned, since it's the
foundation for a hundred hundreds of protocols.

I see how we want [comments, posting, uploading, interaction, talking]
between the clients and the server. The equiv of "textarea" and dinky
li'l radio buttons, and POST requests are necessary for that. But where
are the fences? Slippery slope? More like abyss sans railing.

Sometimes there IS very good reason to scrap and start over. To
voluntarily do a https://imgs.xkcd.com/comics/standards.png because you
have experience with possible use cases, good and bad, and you know how
to implement a simpler, coherent solution to sit beside the palimpsest
of wire hangers and chewing gum that preceded and inspired it.

Starting a new pile of junk next to the old pile of junk because you've
started having a hard time finding things in the old pile will
ultimately just leave you with two piles of junk.

The question raised by this isn't just "why Dioscuri?" It's "why should
we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz
for this problem?" That isn't rhetorical. There could be good answers. I
just can't think of them.

The road to reckless complexity is spelled NIH with a ribbon bookmark.

It was thus said that the Great Sandra Snan once stated:
> We'll look back years from now when gemspace collective standards have a
> complexity that overshadows that of the W3C specifications, and maybe
> we'll recognize that this moment, this post was the Rubicon. Maybe we'll
> think that the Pandora lid was already peeked through to the point of no
> salvation, since an arbitrary sequence of GET requests could become a
> protocol.

  Nope.  The Rubicon was passed earlier this year with talk of the titan:
protocol which allowed people to upload content to a Gemini server and has
already been implemented by at least one Gemini server.  Just go to this
link:

	https://lists.orbitalfox.eu/archives/gemini/2020/thread.html

and search for "titan".  You'll find the threads.  Also search for the
thread "Uploading Gemini Content".  Again, you'll find the threads.

  What I find sad is that this appears to be separate approach from the
titan: proposal, which either means the designers of this were not aware of
of the previous work, or have rejected the previous work for some unstated
reason---I'm hoping it's the former.

> The question raised by this isn't just "why Dioscuri?" It's "why should
> we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz
> for this problem?" That isn't rhetorical. There could be good answers. I
> just can't think of them.

  Again, check the history of this list. It has been discussed before.

  -spc (Who fears that no one realizes that links to the mailing list
	archives are sent in the headers to every message ... )

In which case please reapply my rant to _that_ Rubicon


Sean Conner <sean at conman.org> writes:

> It was thus said that the Great Sandra Snan once stated:
>> We'll look back years from now when gemspace collective standards have a
>> complexity that overshadows that of the W3C specifications, and maybe
>> we'll recognize that this moment, this post was the Rubicon. Maybe we'll
>> think that the Pandora lid was already peeked through to the point of no
>> salvation, since an arbitrary sequence of GET requests could become a
>> protocol.
>
>   Nope.  The Rubicon was passed earlier this year with talk of the titan:
> protocol which allowed people to upload content to a Gemini server and has
> already been implemented by at least one Gemini server.  Just go to this
> link:
>
> 	https://lists.orbitalfox.eu/archives/gemini/2020/thread.html
>
> and search for "titan".  You'll find the threads.  Also search for the
> thread "Uploading Gemini Content".  Again, you'll find the threads.
>
>   What I find sad is that this appears to be separate approach from the
> titan: proposal, which either means the designers of this were not aware of
> of the previous work, or have rejected the previous work for some unstated
> reason---I'm hoping it's the former.
>
>> The question raised by this isn't just "why Dioscuri?" It's "why should
>> we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz
>> for this problem?" That isn't rhetorical. There could be good answers. I
>> just can't think of them.
>
>   Again, check the history of this list. It has been discussed before.
>
>   -spc (Who fears that no one realizes that links to the mailing list
> 	archives are sent in the headers to every message ... )

Sandra Snan <sandra.snan at idiomdrottning.org> writes:

> "Oh, it's chill, any particular client and any particular server can use
> this for ANY semantics" only makes me more concerned, since it's the
> foundation for a hundred hundreds of protocols.

I strongly agree with you.

IMO, we should resist the temptation to make Gemini a general-purpose
application platform, and the like temptation to build a general purpose
application platform alongside it.

I prefer the idea of writing protocols that are specific to applications
(or classes of applications). A protocol for email; a protocol for
message boards; a protocol for file transfer. And a proliferation of
both clients and servers for each protocol. The use of HTTP for
everything has led to every site being an incompatible siloed
application... I'll save the rest of the rant for a gemlog post.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

On Sun, Sep 27, 2020 at 9:59 PM Meff <meff at meff.me> wrote:


> Does Dioscuri have the same line-length limits as Gemini?
>

Yes.  That means that you can't have quite as long an URL as in Gemini.
However, I suspect few people will do Gopher/Gemini-style searches through
Dioscuri.

Do you mean "70" here instead of "60"?
>

I picked 70 more or less at random, then went back and saw that 5x is the
highest Gemini status code, so I'll go with 60.  I didn't quite consummate
the change.


> Are there any limits on payload length from the client?


No, any more than there are limits on payload length from the server in
Gemini (or Dioscuri).


> Are there any
> plans for the client to indicate to the server the length of the
> payload?


That's the point of the one-sided close.  If we had to batch requests on
the same TCP connection, Content-Length would be indispensable, but as
things stand, closing the write side of the socket conveys that information.


> What happens if the server encounters a fault while reading in
> the entire client payload?
>

That's pretty vague: what kind of a fault?  The safe answer for the server
is "Close the connection", at which point the client will figure out (after
TCP timeout) that the request didn't work and apply its general policy
(abort, retry, or ignore) for such events.


> Is there any guidance on timeouts? Should implementors assume that
> timeouts are quick and the server should hangup quickly if nothing is
> found on the client's send stream, or is this application dependent so
> that it's up to the server/endpoint to determine timeouts (e.g. for a
> streaming application)?


The latter, I think.  The Gemini protocol definition mentions timeouts only
in connection with CGI.


> My worry is that opening connections to the
> server and keeping the server send connection open can quickly exhaust
> the number of sockets/fds the server has available.
>

With the Internet the way it is, servers must be written to defend
themselves against both intentional and unintentional attacks in any case.
But the difference between use and abuse depends on the use.  Sockets can
equally be overwhelmed by a Gemini attack.  DDOS protection helps here.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/1af6
7ced/attachment.htm>

On Mon, Sep 28, 2020 at 3:15 AM Sean Conner <sean at conman.org> wrote:

Nope.  The Rubicon was passed earlier this year with talk of the titan:
> protocol which allowed people to upload content to a Gemini server and has
> already been implemented by at least one Gemini server.


You could with equal justice say that publishing Gemini crossed the
Rubicon, since I would certainly never have thought of Dioscuri without
first hearing of Gemini (and being fascinated, since it was clearly a very
nice extension of Gopher's ideas, which I have always loved).


>   What I find sad is that this appears to be separate approach from the
> titan: proposal, which either means the designers of this were not aware of
> of the previous work, or have rejected the previous work for some unstated
> reason---I'm hoping it's the former.
>

I wrote down an early version of Dioscuri when I had barely heard of
Titan.  Later, #gemini pointed me to Titan and I looked at it.  I wasn't
able to find a protocol description and had to reverse engineer it from the
Bash code, but it seemed to me that it was too limited: it provided upload
only, rather than a conversational protocol like I wanted in which
responses were symmetrical with requests.  So I have not so much rejected
Titan as decided that my goals were sufficiently different.


> > The question raised by this isn't just "why Dioscuri?" It's "why should
> > we not use sftp, https, JSON, XML, sexp, IRC, SMTP, foo bar baz frotz
> > for this problem?" That isn't rhetorical. There could be good answers. I
> > just can't think of them.
>

(S)FTP was in fact part of the inspiration for Dioscuri, but I wanted
something much similar.  My earlier version of D. had GET/PUT/POST/DELETE
verbs and the possibility of extensions, but #gemini participants convinced
me that POST was sufficient, provided three cases were well handled:  (a)
no request body (b) no response body (c) the ability to respond with an URL
rather than an anonymous body.  I think I have done that.

JSON, XML, and S-expressions are formats and are all fine: I mentioned JSON
for familiarity, but exchanging information in .INI file format is
perfectly fine (and in fact it can be made isomorphic with XML).

Above all, DIoscuri is both simple and general.  That's not an easy target
to hit, and it's clear to me that Gemini has hit it.  I might quibble about
some details, but I won't.  I have done my best to hit the (slightly
different) target too.

  Again, check the history of this list. It has been discussed before.
>

I read through as much of this year's archives as I could, and I haven't
seen anything bidirectional like this.  Please point me to appropriate
emails if there are any.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
He who would do good to another must do it in Minute Particulars;
General Good is the plea of the scoundrel, hypocrite and flatterer:
For Art and Science cannot exist but in minutely organized Particulars.
  --William Blake, il miglior fabbro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200928/9c15
807f/attachment.htm>

On Mon, 28 Sep 2020, Jason McBrayer wrote:

> IMO, we should resist the temptation to make Gemini a general-purpose
> application platform, and the like temptation to build a general purpose
> application platform alongside it.

The ease and enjoyment of creating a reasonably good server or client for 
the Gemini protocol/format has led to perhaps more clients and servers 
than we need; a positive consequence has been to increase the amount of
caution with which spec changes are now approached.

I think however there is a negative consequence: attention is diverted 
from complementary aspects of the Gemini ecosystem, namely Gemini-native 
content itself, and the tooling connected with it, such as distribution, 
discovery and syndication tools. If there were a simple, fun standard/spec 
for some aspect of these tools, that might attract the same useful energy 
as the Gemini spec itself does.

(As indicated above, I am pretty sceptical about additional 
Gemini-adjacent protocols as such)

Mk

> On Sep 28, 2020, at 15:07, John Cowan <cowan at ccil.org> wrote:
> 
> I read through as much of this year's archives as I could, and I haven't 
seen anything bidirectional like this.  Please point me to appropriate 
emails if there are any.
> 


Look for inimeg (gemini spelled backward :P, circa June '00, re: 
gemini+submit:// (was Re: Uploading Gemini content ) )

Martin Keegan <martin at no.ucant.org> writes:

> I think however there is a negative consequence: attention is diverted from
> complementary aspects of the Gemini ecosystem, namely Gemini-native content
> itself, and the tooling connected with it, such as distribution, discovery and
> syndication tools. If there were a simple, fun standard/spec for some aspect of
> these tools, that might attract the same useful energy as the Gemini spec itself
> does.

Yeah, I think there's potentially a lot to be done here. Even just some
examples, like a desktop app that lets you write and publish a journal
with no server knowledge.


-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

> On Sep 28, 2020, at 6:09 AM, Martin Keegan <martin at no.ucant.org> wrote:
> 
> On Mon, 28 Sep 2020, Jason McBrayer wrote:
> 
>> IMO, we should resist the temptation to make Gemini a general-purpose
>> application platform, and the like temptation to build a general purpose
>> application platform alongside it.
> 
> The ease and enjoyment of creating a reasonably good server or client 
for the Gemini protocol/format has led to perhaps more clients and servers 
than we need; a positive consequence has been to increase the amount of
> caution with which spec changes are now approached.
> 
> I think however there is a negative consequence: attention is diverted 
from complementary aspects of the Gemini ecosystem, namely Gemini-native 
content itself, and the tooling connected with it, such as distribution, 
discovery and syndication tools. If there were a simple, fun standard/spec 
for some aspect of these tools, that might attract the same useful energy 
as the Gemini spec itself does.

I think a lot of us would rather work on Gemini things rather than 
served-up-over-Gemini things. Might be a pent-up-demand kind of thing.

(says the guy who?s splitting his time between a static-gemlog generator 
and actually writing stuff for his capsule when he really should just do the latter)

Jason McBrayer <jmcbray at carcosa.net> writes:
> IMO, we should resist the temptation to make Gemini a general-purpose
> application platform, and the like temptation to build a general purpose
> application platform alongside it.

The good old days when we had separate apps for everything was paradise
for me, and, well, still is because I can still happily live in that
world in my li'l Debian bubble.

You've seen me rant against web apps before, for example on here:
https://github.com/w3c/web-share/issues/173

But it was not easy for most people to ./configure, make, make install
things. Using web apps is something they can do.

As an example, email exploded once web-interfaces to email became
available.

If Gemini and adjacent protocols turn into a general-purpose application
platform, there need to be some sort of purpose or guiding light or
boundaries or reason for starting a new pile instead of working on the
already existing pile of junk.

Dioscuri doesn't have a client-side, server-served programming language.
Such things are the cause of a lot of the web's problems so that's not
what I'm proposing, but, the consequence of _not_ having it means that
every Dioscuri?app needs to have its own implementation.

Talk about complexity in the client! With SSH I can have an app on the
remote and call it from my client.

ssh some-server-name 'ls|tail'

The SSH client doesn't need to know or implement the semantics of ls or
tail. With Dioscuro, there is a lot of responsibilty for both sides to
be on the same page with regards to semantics.

Sandra

PS.
Here's an idea, in the mindset of green hat "thinking out loud":

*If* there were to be a new general-purpose application platform
along-side Gemini, client side should be "dumb" and the protocol (i.e.
the interface between client and server) also needs to be simple and
specific.

A handful of standard UI elements communicating with server back and
forth in a straight-forward way according to one specific protocol.

The following is not gonna sound retro, but? if parts of the page could
update without reloading the entire page, that'd go a long way to
alleviate a lot of people's desire for JavaScript, AJAX etc. One button,
one checkbox, one text field etc could be sent without having to send
the entire form, and one local UI area could be updated without having
to refetch the entire page.

I.e. the client holds only the view and the user inputs. It should be
like pushing on remote buttons with a ten foot pole on the other side of
a chasm.

PPS.
OTOH, what I just described sounds like it could turn a FOSS nightmare
that there ain't no AGPL strong enough to prevent, so uh, don't hold me
to that idea. Just thinking out loud.

Sandra Snan <sandra.snan at idiomdrottning.org> writes:

> The following is not gonna sound retro, but? if parts of the page
> could update without reloading the entire page, that'd go a long way
> to alleviate a lot of people's desire for JavaScript, AJAX etc. One
> button, one checkbox, one text field etc could be sent without having
> to send the entire form, and one local UI area could be updated
> without having to refetch the entire page.

You might be interested in looking at intercooler.js
(https://intercoolerjs.org/) and HTMX (https://htmx.org/), which
implement this pattern in the browser. Of course, browsers don't
natively support HTMX, so it's written in JavaScript; but a browser
*could* implement almost all of it without also implementing JavaScript.

Of course, it seems to me that this is also how IBM 3270 terminals
worked, more or less.

-- 
+-----------------------------------------------------------+
| Jason F. McBrayer                    jmcbray at carcosa.net  |
| A flower falls, even though we love it; and a weed grows, |
| even though we do not love it.            -- Dogen        |

June '00? Wow, I was later to the Gemini party than I thought.

Sandra

PS I feel bad for shooting down Dioscuri so harshly, I hate being such a
parade-rainer. jcowan is one of my idols


Petite Abeille <petite.abeille at gmail.com> writes:

>> On Sep 28, 2020, at 15:07, John Cowan <cowan at ccil.org> wrote:
>> 
>> I read through as much of this year's archives as I could, and I 
haven't seen anything bidirectional like this.  Please point me to 
appropriate emails if there are any.
>> 
>
>
> Look for inimeg (gemini spelled backward :P, circa June '00, re: 
gemini+submit:// (was Re: Uploading Gemini content ) )

On Wed, Sep 30, 2020 at 12:14 PM Sandra Snan <sandra.snan at idiomdrottning.org>
wrote:


> The good old days when we had separate apps for everything was paradise
> for me, and, well, still is because I can still happily live in that
> world in my li'l Debian bubble.
>

I live in that world too.  But there are only a few of them: ftp, ssh and
friends, mail, etc.  I have no trouble learning them all.  But they are
very inconsistent, much like Posix command-line tools.


> As an example, email exploded once web-interfaces to email became
> available.
>

I'm not sure if you think that's good or bad.  See <
http://www.catb.org/jargon/html/S/September-that-never-ended.html>.


> If Gemini and adjacent protocols turn into a general-purpose application
> platform, there need to be some sort of purpose or guiding light or
> boundaries or reason for starting a new pile instead of working on the
> already existing pile of junk.
>

Well, why work on Gemini instead of just using HTML and HTTP?  Simplicity
Gemini and text/gemini are simple enough without being too simple.  I
believe that Dioscuri is too.


> Dioscuri doesn't have a client-side, server-served programming language.
>

There's no reason Gemini can't ship JavaScript, or Scheme for that matter.
"JavaScript: The Good Parts" actually describes a very nice little language.

Talk about complexity in the client! With SSH I can have an app on the
> remote and call it from my client.
>
> ssh some-server-name 'ls|tail'
>

Yes, you can, but the server is at risk if it allows you to ssh and run
arbitrary shell commands.  Posix systems are better defended than most, but
the firewall is far from complete.

*If* there were to be a new general-purpose application platform
> along-side Gemini, client side should be "dumb" and the protocol (i.e.
> the interface between client and server) also needs to be simple and
> specific.
>

The trouble is that for decades now almost all the CPU power in the world
has been client-side, most of it underused.  Downloadable smart clients
keep the strain off the servers.  That fact will be with us for the
foreseeable future (phones are somewhat weaker, but there are a lot more of
them).


> A handful of standard UI elements communicating with server back and
> forth in a straight-forward way according to one specific protocol.
>

That's how HTML/HTTP began, and we know where that led to.  I was striving
for something different, *starting* from a smart client, downloadable or
not, and a fairly dumb server, which is where the web is moving now (see
"single-page application").  In particular, this means that the client
doesn't have to be a GUI or a TUI like lynx/w3m/etc.  It can be a CLI or a
batch job or any number of other things.  "Pages? What pages?  We don't
need no steenking pages!"

Intercooler does look interesting: I'm going to explore it further.

I once saw an application that had been converted from 3270 to a Windows
desktop product. I had been asked to give it a quick tryout to see how the
UI worked.  I went back to the programmers and told them that no Windows
user would put up with this complete lack of control.  The back end needed
to be event-driven.  Of course, the browser restored the 3270 model
completely.

PS I feel bad for shooting down Dioscuri so harshly, I hate being such a
> parade-rainer. jcowan is one of my idols


No problem.  Idols often have feet of clay, after all.




John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Using RELAX NG compact syntax to develop schemas is one of the simple
pleasures in life....          --Jeni Tennison
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201008/054f
44b9/attachment.htm>