💾 Archived View for rawtext.club › ~sloum › geminilist › 001681.gmi captured on 2020-11-07 at 02:23:36. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Luke Emmet luke at marmaladefoo.com
Sun Jun 14 22:06:11 BST 2020
- - - - - - - - - - - - - - - - - - -
On 14-Jun-2020 16:05, solderpunk wrote:
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.
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.
I think this is a great idea! It would go quite a long way to supporting collaborative editing. And as you say it is infrastructure we already have.
if your lines are about 25 characters long, 2kb is about 80 lines worth of text. That seems a nice sweet spot to me.
We could argue if you need more than that you will be better placed to find a more flexible upload option.
The only other part to the jigsaw in my view is a way to integrate the editing experience into the client so you can *round-trip* the content. As we know the first edit is seldom a perfect one.
The basic wiki concept has the following:
1. Page displays content (we can do that)2. Edit mode of the existing page content3. Upload (2k allowed - OK)4. Review submitted content (return to 1)
For step 2, we want the user to be able to edit the existing content, not necessarily compose completely afresh.
One suggestion is that clients MAY present an integrated editor bound to a preformatted region on a page (perhaps the first one or a user selected one). This allows the re-editing of the existing content. This is then what is submitted when writing back via the submission.
This would cover the full lifecycle of simple yet basic wiki editing.
Best Wishes
- Luke