[Spec] Spec (un)freezes and the spec's future

[John Cowan]

On Sun, Dec 20, 2020 at 9:58 AM Solderpunk <solderpunk at posteo.net> wrote:

Things don't need to be 100% perfect to be useful.  I think it's
> arrogant to *aim* for perfection.


Author:  "I know there are some mistakes in my book; after all, it is 777
pages long!"

Editor: "If you know there are mistakes, why don't you _fix_ them?"

I know it's very much going against
> the grain to declare than any kind of software project is "done"; I know
> that people nowadays explicitly avoid using or recommending software for
> the sole reason that it is no longer being actively developed.
>

"Some software is abandoned; other software is merely finished."  --me

(If you don't care about companion protocols and Dioscuri, skip the rest.)


> Our strongest possible defense here, IMHO, is keeping the core protocol so

easy to implement that there is always likely to be a wide variety of
> clients in popular use.  That way, companion protocols cannot gain
> traction unless multiple independent client developers all agree they
> are worth supporting.


As someone whose proposed extension protocol has probably made the most
noise, I would point out that Dioscuri clients and servers will typically
*not* be Gemini clients and servers, as they don't share the same use cases
at all.  Dioscuri native applications and front-end engines are not
browsers, and Dioscuri servers are more like Tomcat than like Apache.

To hold down on the number of posts, I'll just mention that the spec for
Dioscuri is now at <
https://gist.github.com/johnwcowan/d3211496ad89125c77297c6586ebe176>.  I
will probably edit it further, especially if there are changes in the
Gemini spec that also make sense for Dioscuri.  The TL;dr version of the
protocol is that the client sends a media type along with the URL; and
follows it with an appropriate body; otherwise it is the same as Gemini.

I want to specially acknowledge Sandra Snan, who said that Dioscuri needed
a server-served, client-executed programming language to make a front-end
engine programmable.  I agree, and I'm now working on just such a
language.  My sources so far are ABC (the ancestor of Python), PROMAL (a
programming language for Apple II and Commodore systems), Perl 1.0,
Microsoft Small Basic, and the libplot library, plus the ability to execute
REST requests at least via Gemini and Dioscuri.  It will have much the same
goals as Gemini (see the FAQ) insofar as they are applicable to language
design, and will be aimed at beginning and perpetual-intermediate
programmers without being too excruciating for advanced programmers.



John Cowan          http://vrici.lojban.org/~cowan        cowan at ccil.org
Her he asked if O'Hare Doctor tidings sent from far coast and she with
grameful sigh him answered that O'Hare Doctor in heaven was.  Sad was the
man that word to hear that him so heavied in bowels ruthful.  All she
there told him, ruing death for friend so young, algate sore unwilling
God's rightwiseness to withsay.   Joyce, Ulysses, "Oxen of the Sun"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201220/9718ffe3/attachment-0001.htm>