Luke Emmet luke at marmaladefoo.com
Sat Jun 13 14:06:48 BST 2020
- - - - - - - - - - - - - - - - - - -
Hi everyone
I've been thinking some more about this self-editing wiki concept, which seems a great application to support writers of Gemini content. I think there is an opportunity for a very simple addition to Gemini that would support client based content submission.
The mental model is quite simple - imagine a simple web page, having a single text area and a single submit button. The user can edit the text and submit the content. The client knows where to send the content (form attribute) and how to send it (HTTP protocol using POST).
Exactly what the name for this doesnt really matter, and it will need to integrate with the authentication/certificates mechanisms we already are establishing.
Essentially there are a number of new elements
1. New scheme extending gemini, only for those that want to. This is not gemini, but something else. Whether it gets considered for gemini is a separate conversation.
2. An extended client behaviour working with the preformatted text regions having suitable markers to be defined
3. A simple text submit protocol (text/plain only, UTF-8 only)
The elements could look like this
1. The scheme name is gemini+submit:// or something, doesnt really matter, but is distinct from gemini://.
2. Using the preformatted regions to specify the URL end point to post to. Only end points having gemini+submit:// as the scheme would have an active behaviour. This is done in a backwards compatible way so simpler clients just render the content as preformatted text
Note we use 4 back ticks to convey that the content may be edited and submitted. There could be some other option to indicate this, the syntax marker is not significant, can be changed to ```! or something else. This gracefully degrades and is valid text/gemini
the 4 back ticks mean existing clients will just show the text.
The URI will probably contain information for the server to know where to put the content such as:
asset-id=1234ae4f34ae
or
path=/path/on/filesystem/to/file.gmi
3. The client allows the user to edit the content and then "submit" (button or whatever) the content to the end point as follows:
CONTENTLENGTH<SPACE>FULL_URI_FROM_TEXT_AREA<CR><LF><client sends the byte content><client closes connection>
Only text/plain is ever sent so we don't need to specify mime type. Simple and restricted.Only UTF is ever sent, so we dont need to specify it. Simple and restricted.
There is only ever one "block" of text submitted, which is the content of the preformatted area (no multi-field forms).
The end point on the server knows when content has arrived as the content length is pre-notified in the header, replies with redirect to success page probably.
server may also respond requesting input,certificates
on the server, the end point might be inside the server or could be a CGI or similar application that might get the content via stdin (as per POST for HTTP)
It would be nice to adopt a common scheme for this together with gemini+put:// (for arbitrary binary upload) and gemini+delete:// suggestions suggested earlier on this thread. For example to integrate certificates, success or failure etc.
Potentially this scheme can be used to edit simple text content of a number of back end applications.
There are no changes need to any client or server that is not interested to implement this.
I think this has a similar simplicity to the spirit of Gemini and does not open huge doors for a horse and cart to come through.
Best Wishes
- Luke