💾 Archived View for gemlog.blue › users › roberto_vpt › 1638382034.gmi captured on 2023-03-20 at 19:28:34. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2021-12-04)
-=-=-=-=-=-=-
My initial proposal was not aligned with the uses of the Gemini community, which mainly use text-based interfaces.
Later I tried to implement my ideas by supporting common use.
Today we discuss the use of inserting ANSI codes directly into gemtext just like unicode characters.
I don't think it's good because, for example, they lend themselves to inserting key sequences or control codes that are difficult to interpret.
Indeed it would be better to declare which are the allowed control characters and their use.
Using ascii characters as visual formatting markers is the norm and so I just embellished the texts and added justification.
""As this is in italic.
**The correct use of the markers is devolved to the writer.
This version in Lua is designed to be used in the solderpunk DEMO client without substantial modifications.
gemini+submit _ (was Re Uploading Gemini content)
On Sun, Jun 14, 2020 at 02:33:52AM +0200, Petite Abeille wrote:
Unfortunately, the 1024 bytes limit doesn't get us very far. The diff itself is ~14K. ~5K compressed. Too big for one request.
Fossil delta format [2] is much more compact than diff -u, but still weights ~4K, 2K compressed. And this is not accounting for data: encoding overhead.
So, hmmm, 1024 bytes is quite a limiting factor if one must use only one request.
Well, look - 1024 bytes as a maximum URL length is a value I more or less plucked out of the air without deep consideration, simply because the elements passed around by a protocol *should* have a welldefined maximum length so people can allocate appropriately sized memory buffers, etc. I certainly *wasn't* thinking about using queries to upload content, I was thinking of "ordinary URLs" and so 1024 bytes seemed hugely generous.
I believe most web browsers have a larger maximum URL length. I did look into this briefly for some reason - IIRC, Internet Explorer has/had the smallest limit, and it was either 2048 or 4096 bytes.
According to GUS, currently more than half of the text/gemini content out there is *less than 1.2 KiB in size*.
If URLs were allowed to be 2048 bytes long, all that content could be uploaded as a query.
I do not have hard numbers on this (Alex may be able to provide them), but I would *imagine* that most edits to wikis, when expressed as diffs, would also be much less than 1 KiB.
Can we solve a lot of these issues by bumping up our maximum URL length and, perhaps, defining a new 1x status code meaning "I'm asking you for some input and in this context it's quite reasonable that you might want to submit something on the long side", *which clients could optionally respond to by launching a text editor* instead of just reading a single line of input? Clients which chose to support this code would become the preferred clients of wiki enthusiasts or people who don't want to or don't know how to use scp etc.
Heck, wiki nerds could write their own clients which can launch an editor pointed at a local copy of the resource being viewed, then calculate a diff in some format and submit *that* as a query, and the wiki software the server runs could apply the diff. The special wiki editing clients could even do your suggested chunked transfer thing for very large diffs, if the wiki servers all implemented a standard API for such a thing.
It should also be very easy to write an app targetted at "non-technical" authors which lets them submit chunks of writing up to 2 KiB or so, with an "append" link at the submission confirmation page to submit a follow up chunk. It wouldn't necessarily be the smoothest experience in the world, but if most content could be written in a single request and 99% with one or two "append" requests, I think it would be usable enough. Heck, this is the "slow internet", right? A little bit of inconvenience as part of a careful and deliberate process should not scare us away.
In general, solving perceived problems with the limitations that Gemini imposes by combining the "primitives" which are already there in creative new ways, even if they are very slightly clunky, makes me far, far happier than adding in additional more advanced features to remove those limitations. If we discover really useful and generally applicable constructions that can be built in this way, we can give them names, standardise them, and clients can choose to impelement them in ways which hide the clunkiness from the user. It would be wonderful, though, if they were still usable in a clunky way by a knowledgable users in clients which didn't support them explicitly.
In short, think like FORTH. :)
A bit clunky, but workable :D
Maybe we should adopt this as an official motto? :p
Cheers,
Solderpunk