💾 Archived View for rawtext.club › ~sloum › geminilist › 001672.gmi captured on 2020-09-24 at 01:43:36. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
solderpunk solderpunk at SDF.ORG
Sun Jun 14 16:05:47 BST 2020
- - - - - - - - - - - - - - - - - - -
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 orless plucked out of the air without deep consideration, simply becausethe elements passed around by a protocol *should* have a well-definedmaximum length so people can allocate appropriately sized memorybuffers, etc. I certainly *wasn't* thinking about using queries toupload content, I was thinking of "ordinary URLs" and so 1024 bytesseemed hugely generous.
I believe most web browsers have a larger maximum URL length. I didlook into this briefly for some reason - IIRC, Internet Explorer has/hadthe smallest limit, and it was either 2048 or 4096 bytes.
According to GUS, currently more than half of the text/gemini contentout there is less than 1.2 KiB in size. If URLs were allowed to be 2048bytes 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 lengthand, perhaps, defining a new 1x status code meaning "I'm asking you forsome input and in this context it's quite reasonable that you might wantto submit something on the long side", which clients could optionallyrespond to by launching a text editor instead of just reading a singleline of input? Clients which chose to support this code would becomethe preferred clients of wiki enthusiasts or people who don't want to ordon't know how to use scp etc.
Heck, wiki nerds could write their own clients which can launch aneditor pointed at a local copy of the resource being viewed, thencalculate a diff in some format and submit *that* as a query, and thewiki software the server runs could apply the diff. The special wikiediting clients could even do your suggested chunked transfer thing forvery large diffs, if the wiki servers all implemented a standard API forsuch 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, withan "append" link at the submission confirmation page to submit a followup chunk. It wouldn't necessarily be the smoothest experience in theworld, 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 inconvenienceas part of a careful and deliberate process should not scare us away.
In general, solving perceived problems with the limitations that Geminiimposes by combining the "primitives" which are already there increative new ways, even if they are very slightly clunky, makes me far,far happier than adding in additional more advanced features to removethose limitations. If we discover really useful and generallyapplicable constructions that can be built in this way, we can give themnames, standardise them, and clients can choose to impelement them inways which hide the clunkiness from the user. It would be wonderful,though, if they were still usable in a clunky way by a knowledgableusers 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