gemini+submit:// (was Re: Uploading Gemini content)

[Luke Emmet]

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

````gemini+submit://domain/end-point/handler?any-params-you-like-probably-includes-asset-id-or-path

```` (could be 3 or 4 doesnt really matter)

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