💾 Archived View for rawtext.club › ~sloum › geminilist › 001620.gmi captured on 2020-10-31 at 02:24:31. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2020-09-24)

-=-=-=-=-=-=-

<-- back to the mailing list

Uploading Gemini content

Luke Emmet luke at marmaladefoo.com

Sat Jun 13 09:26:50 BST 2020

- - - - - - - - - - - - - - - - - - - 

On 13-Jun-2020 08:05, Sean Conner wrote:

One of Sir Tim Berners-Lee's initial ideas for HTTP was to allow the user
to edit the page in the browser and have that update the file on the server.
HTTP didn't get this capability until May of 1996 [1] where various methods
were defined that included PUT and DELETE. It's sad to think that no
browsers at that time even attempted to do that [2]. Instead, we kept on
using FTP, later sftp and maybe even rsync for the technically minded.

Actually there was Amaya (defunct 2012) which was a W3 reference browser which implemented read and write for the web. There was also a version of Netscape Navigator (3.04 Gold) that had something too.

https://www.w3.org/Amaya/

https://www.webdesignmuseum.org/old-software/web-browsers/netscape-navigator-3-04

Sadly it never really took off as it is less than 1% (n.b. made up statistic) of people that write the content on the web, so no-one really needed that functionality. But in Gemini, the readers and writers are a more overlapping set, as the barriers to participation are lowered.

However, as we all know, what really did explode was the wiki concept of being able to edit content in your browser, which has led to the plethora of editable websites we see today and markdown.

I'd really like to see a simple concept in gemini (+friends) of being able to do this. It would be good to thrash this out.

We already have the simplest, most useful text based markup language, so that bit is done.

I think your ideas for a schema are a good start.

C: gemini+put://example.com/path/to/new.txt?mime=text/plain&size=1024 CRLF
S: 1x continue CRLF
C: size bytes of content

I would like to see the target path be a percent encoded parameter to the end point, otherwise we cannot so easily implement multiple end points on the same server. For example there might be a number of different server of CGI applications able to receive content on the same server or domain.

so maybe something like this is a more flexible way to specify the put request

C: gemini+put://example.com/put-handler?path=path/to/new.txt?mime=text/plain&size=1024 CRLF<continues>

One idea I've been working with is to integrate this with the preformatted area of a page, and then the client could render certain types using a text editor, something like this:


this content can be edited by the user and the client provides a button somewhere to "submit" it

On submitting, the mime=text/plain and size=XYZ is provided

Best Wishes

- Luke