Hi Solderpunk,
Thanks for taking the time for exposing things in full.
I did due diligence before posting here. I read all materials at
gopher://zaibatsu.circumlunar.space:70/1/~solderpunk/gemini as well as
enkiv2's and John Olmo's pieces. Also nearly all of this list's
archived emails.
That is to say, I believe I have a good grasp on the philosophy
behind Gemini and the principles that have guided it's evolution. Let
me spell it clearly: To those principles I violently agree!
I'll be cherry-picking topics below were actual disagreement exists.
On Tue, Nov 26, 2019 at 19:06:30 +0000, solderpunk wrote:
> But I am concerned, and consistently have been all throughout
> Gemini's development, about making sure we don't provide a toehold
> for extensibility to creep in.
Sorry to say, that ship already sailed the moment => was
specified. The most you can do is to make some hard requirements in
the specification.
In all honesty, it sailed even before that, when mime types were
adopted. What's to prevent some Gemini server to serve text/html with
external js indeed? What's to prevent certain clients from rendering
such content as a web browser does?
I'm not trying to open a new discussion here. We all know this is just
an matter of balance.
> I am firmly of the belief that open-endedness and extensibility are
> nothing but poison for a project which wants to remain small and
> simple and to strongly enforce certain ideals.
Agreed, but... A standard that falls short of its intended purpose
in life is just calling for the very same kind of de-facto
standardization you so well describe for http.
> Thus, my big concern about using == as a start-of-line marker to
> indicate verbatim text (and let me be very clear that I recognise
> and appreciate the beauty of using this common notation for equality
> to mean "present exactly this"!)
== possesses a certain beauty and elegance about it, doesn't it? :-)
At any rate which actual marker is adopted is of no consequence. Let's
call it the 'verbatim marker' from here on.
> [...] is that it might soe the seed of the idea that the text/gemini
> syntax is one where features are defined by two character markers
> where the first character is =. If => is special and == is special
> then if we ever decide to add explicit representation of bullets
> everybody will have to agree it is obvious and consistent that this
> be done with =* and by this point the war is lost. =$ and =# and =?
> are all fair game. Someday somebody will propose that [...]
I get it, really. Let me try to convey why I state this does not apply
to the verbatim marker: it is an unavoidable requirement.
In fact there's two unavoidable requirements at stake here.
1 - There must exist an option for the client for reflowing text. I
won't elaborate much here. There's simply no way verbatim
formatted text will look good simultaneously on big desktop
screens and small smartphone displays. Doing that according to
an RFC backed set of precise rules is nothing but 'the right
thing' (TM).
2 - In the presence of 1, some way to specify verbatim formatted
text lines MUST exist for the Gemini author.
Number 1 will always be an option for the client, be it in the spec
or not. So better handle it in an unambiguous way to avoid a myriad
of, client chosen, different ways.
The capitalized MUST in 2 reflects the fact that it's a fundamental,
intrinsic, requirement for any text content distribution
platform. There're sure many more use cases. I mentioned Python source
and mathematical formulas.
It might be an inconvenience having C source code garbled, but it
will compile anyway, and can be automatically reformatted. That is
not the case with Python code, with its syntactically relevant use of
white space.
Take a Python snippet, reflow it, and you just lost its semantics.
It won't run. It cannot be automatically reformatted. Depending on
code complexity, even manual reformatting might be impossible. Simply
put, information has been irremediably lost at this point.
Now take a simple polynomial expression. Exact same situation
arises when the reader cannot discern which numerator goes with which
denominator.
In short, I object this is just a desirable feature of the
text/gemini format, as you state elsewhere in your reply.
Admittedly this could be subsumed in a more general markup facility
if the markup du jour was to be adopted, with all its nice to have
text styling and structuring features. Fact remains verbatim
formatted text must be available regardless.
If not specified, someone will implement this sooner than latter, in
a not controlled way. It might get generally liked, hence adopted.
Back at square one then.
Or someone will start experimenting on how to abuse with => markers
in order to somehow achieve this kind of thing. Coincidentally, the
spec is not yet finalized and this has already begun with some
result. Check
gemini://gemi.dev/gemini-mailing-list/messages/000019.gmi in this
very same list.
What's to be expected once the spec is set on stone?
> This is precisely the reason that when the question came up as to
> how we should best implement something like Gopher's item type 7 in
> a system without item types, I rejected the notion (even though it
> seems to make perfect sense) that we use =? instead of => for search
> points (I *think* this was julienxx's idea?).
That, I believe, would have been just a case of bad tool for the job
that was very appropriately handled IMHO.
> [...] and I admit that Gemini is slightly more naturally immune to
> this than HTML is - Gemini clients are by design very simple, which
> means many people will write them, which means there is less likely
> to evolve a situation where a small number of highly influential
> clients [...]
Also worth of consideration: general user population will likely be
composed of disgruntled former web users in one hand and former gopher
users on the other. I don't expect any of these groups to be
interested in such an outcome. Both had the web option available
before gemini; both opted out.
> This principle of not inviting future extension has informed a
> number of decisions about the Gemini protocol.
As stated above, I fully agree with this approach. Anyway, sometimes
you must handle the smaller evil in order to avoid the big one.
> [on the use of syntactic white space]
I don't think I need to expand on how an atrociously bad choice
white space would be. This very same email would be rendered in a
mixture of formatted and reflowed paragraphs :-)
> frustrating that is. I do certainly agree with both of your
> premises, that some solution to widely varying screen sizes and some
> way to embed unreflowd text, are very highly desirable.
I beg to disagree on the "desirable" bit, you know :-P
I personally would settle with any solution not involving stealth
white space markers. Client driven text reflow cannot be ruled out, so
verbatim formatted text must be in the spec in some form or another.
>> If you happen to have endured my prose all the way down here, many
>> thanks for your attention. You're a remarkably forgiving reader.
> Don't worry, I have been working hard for months to scare anybody
> without a very high tolerance for verbosity far away from anything
> to do with Gemini. :)
Well, I'd say both of us seem to lean a bit on the loquacious side...
Best regards,
Andram
---
Previous in thread (2 of 9): 🗣️ solderpunk (solderpunk (a) SDF.ORG)
Next in thread (4 of 9): 🗣️ Brian Evans (b__m__e (a) mailfence.com)