πŸ’Ύ Archived View for gemi.dev β€Ί gemini-mailing-list β€Ί 000743.gmi captured on 2023-12-28 at 15:52:08. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2023-11-04)

🚧 View Differences

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

Supporting multi-line input without changing the specification

1. Katarina Eriksson (gmym (a) coopdot.com)

Since we're still getting proposals, I'm writing something I read somewhere
gemini related. I do not claim I invented this myself. (Except the codes at
the bottom.)

# Objective

Provide a way for users to send bigger chunks of text to the server.

# User experience

Support for regular status 10 input, CGI and client certificates assumed.

## Clients with multi-line support

The reader klicks a link. A text box, with a label from the meta part,
appears. The reader writes and sends the message.

## Clients without multi-line support

The reader klicks a link. An input field, with a label from the meta
part, appears.
The reader writes the first line, end the line with a marker character to
signal a wish to continue and sends the request. The server responds with a
new input until it doesn?t receive that marker character.

It should be easier to exit the loop than to continue.

## Servers

The writer puts a script (or a symlink to a script) in a reasonable
location and link to it in gemtext. The script handles the incoming texts.

# Behind the scenes

The server needs to indicate to the client that it expects a multi-line
text. One way is to send a new 1x status, like 12, but that is a spec
change. Other ways are to use a specific file name extension or a keyword
in the meta field.

I must admit I prefer the new status code over the others. Other options?

The client needs to indicate to the server that it wants to continue the
text in another request. I have chosen & since it doesn't need to be
escaped and doesn't have a specific meaning yet in gemini.

## Example

S: "10 New guest book entry (multi)\r\n"
C: "gemini://guestbook.example/new.multi?Neat%20that%20you%20can%20post%20
multi-line%20texts.&n\r\n"
S: "10 (more)\r\n"
C: "gemini://guestbook.example/new.multi?I%20wonder%20if%20clients%20will%20
adopt%20it.\r\n"

## Codes

I have written a script to experiment with user experience. These are the
codes I came up with:


line.

immediately in the next request. (Can be in the middle of a word.)

blank line.


These codes are made to be typed by a human. A client translating a text
box could just put "%0a" to break a line and end the input with a "&" when
it reaches the maximum request length to continue in the next request.

-- 
Katarina
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210223/ed69
8236/attachment.htm>

Link to individual message.

2. Mansfield (mansfield (a) ondollo.com)

On Mon, Feb 22, 2021 at 5:41 PM Katarina Eriksson <gmym at coopdot.com> wrote:

> Since we're still getting proposals, I'm writing something I read
> somewhere gemini related. I do not claim I invented this myself. (Except
> the codes at the bottom.)
>
> # Objective
>
> Provide a way for users to send bigger chunks of text to the server.
>

<snip>


> --
> Katarina
>

Thanks for experimenting!

I'm exploring something along those lines too - one complication that gave
me some trouble I ended up needing to adjust to: how to *edit* existing
text. Any thoughts around that?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210222/b816
6390/attachment-0001.htm>

Link to individual message.

3. Katarina Eriksson (gmym (a) coopdot.com)

Mansfield <mansfield at ondollo.com> skrev:

> On Mon, Feb 22, 2021 at 5:41 PM Katarina Eriksson <gmym at coopdot.com>
> wrote:
>
>> Since we're still getting proposals, I'm writing something I read
>> somewhere gemini related. I do not claim I invented this myself. (Except
>> the codes at the bottom.)
>>
>> # Objective
>>
>> Provide a way for users to send bigger chunks of text to the server.
>>
>
> <snip>
>
>
>> --
>> Katarina
>>
>
> Thanks for experimenting!
>
> I'm exploring something along those lines too - one complication that gave
> me some trouble I ended up needing to adjust to: how to *edit* existing
> text. Any thoughts around that?
>

Someone built a wiki for use over gemini. It has its own side-protocol for
editing but I don't remember the names.

-- 
Katarina

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20210223/165d
77c0/attachment.htm>

Link to individual message.

4. avr (a) geminet.org (avr (a) geminet.org)

On Tue, Feb 23, 2021 at 04:06:08AM +0100, Katarina Eriksson wrote:
> Mansfield <mansfield at ondollo.com> skrev:
> 
> > On Mon, Feb 22, 2021 at 5:41 PM Katarina Eriksson <gmym at coopdot.com>
> > wrote:
> >
> >> Since we're still getting proposals, I'm writing something I read
> >> somewhere gemini related. I do not claim I invented this myself. (Except
> >> the codes at the bottom.)
> >>
> >> # Objective
> >>
> >> Provide a way for users to send bigger chunks of text to the server.
> >>
> >
> > <snip>
> >
> >
> >> --
> >> Katarina
> >>
> >
> > Thanks for experimenting!
> >
> > I'm exploring something along those lines too - one complication that gave
> > me some trouble I ended up needing to adjust to: how to *edit* existing
> > text. Any thoughts around that?
> >
> 
> Someone built a wiki for use over gemini. It has its own side-protocol for
> editing but I don't remember the names.

That might be "twinwiki"

gemini://gemi.dev/gemini-mailing-list/messages/002078.gmi
gemini://webgate.geminet.org/web.sh?gemini://gemi.dev/gemini-mailing-list/m
essages/002078.gmi

Twinwiki uses sed commands to edit, which I found quite clever and elegant. I think the
trick to making it more approachable is to have a client that allows for 
normal edits but 
translates those into sed commands when updating the page (diff -e ?).

Link to individual message.

5. Sandra Snan (sandra.snan (a) idiomdrottning.org)

avr wrote:
> a client that allows for normal edits but translates those into sed
> commands when updating the page

These kinds of suggestions are along the line of having a client that
supports translating *asterisks* to emphasis, translating <font
family="foo"> to a specific font family, and so on.

There's nothing stopping anyone from implementing that kind of thing at
any moment and if it's gets traction it'll get traction. We're in a
similar situation as what broke the pre-standards web.

There's not a lot me or anyone else can do about that so I don't worry
too much about it??

However, for sending text I recommend email.

Here's an idea for how a wiki in a world where spam didn't exist could
work:

You send email to an address. The text of the page at the path that
matches the subject of that email is then set to the body of the email.

Whether that subject is "nice/orderly/unixy/path" or "Completely bonkers
with spaces that'll need to get percent-encoded and trunced to match the
1024 limit."

If people want to edit they can paste the old text into their new email.

This is just from the top of my head and not something I'd put into
production any time soon.

Link to individual message.

6. Sandra Snan (sandra.snan (a) idiomdrottning.org)

PS not to say that it's a clear cut case.

I generally do think the sed command idea is clever and that it's generally
fine if clients do convenience things, like av98's tour mode.
Aww, foiled once more by Turing and his cursed completeness!

Link to individual message.

7. Solène Rapenne (solene (a) perso.pw)

On 23/02/2021 11:56, Sandra Snan wrote:
> avr wrote:
>> a client that allows for normal edits but translates those into sed
>> commands when updating the page
> 
> These kinds of suggestions are along the line of having a client that
> supports translating *asterisks* to emphasis, translating <font
> family="foo"> to a specific font family, and so on.
> 
> There's nothing stopping anyone from implementing that kind of thing at
> any moment and if it's gets traction it'll get traction. We're in a
> similar situation as what broke the pre-standards web.
> 
> There's not a lot me or anyone else can do about that so I don't worry
> too much about it??
> 
> However, for sending text I recommend email.
> 
> Here's an idea for how a wiki in a world where spam didn't exist could
> work:
> 
> You send email to an address. The text of the page at the path that
> matches the subject of that email is then set to the body of the email.
> 
> Whether that subject is "nice/orderly/unixy/path" or "Completely bonkers
> with spaces that'll need to get percent-encoded and trunced to match the
> 1024 limit."
> 
> If people want to edit they can paste the old text into their new email.
> 
> This is just from the top of my head and not something I'd put into
> production any time soon.
> 

there is nothing preventing users to publish markdown files instead
of gemini files. On gemini, it's not mandatory to have everything as 
gemtext which would be reducing Gemini potential.

Like it is often done in gopher, people can have gemtext files as menus 
with their texts files in markdown that could be opened with a nice 
markdown viewer program, and links with gemini:// scheme from the 
markdown file would be opened using the gemini client. That would be 
like using opening a PDF from a website and clicking on a link in the PDF :)

The workflow may not seem optimal but it's perfectly doable with the 
current state of the protocol.

Link to individual message.

8. raingloom (raingloom (a) riseup.net)

On Tue, 23 Feb 2021 12:10:35 +0100
Sol?ne Rapenne <solene at perso.pw> wrote:

> On 23/02/2021 11:56, Sandra Snan wrote:
> > avr wrote:  
> >> a client that allows for normal edits but translates those into sed
> >> commands when updating the page  
> > 
> > These kinds of suggestions are along the line of having a client
> > that supports translating *asterisks* to emphasis, translating
> > <font family="foo"> to a specific font family, and so on.  
> > 
> > There's nothing stopping anyone from implementing that kind of
> > thing at any moment and if it's gets traction it'll get traction.
> > We're in a similar situation as what broke the pre-standards web.
> > 
> > There's not a lot me or anyone else can do about that so I don't
> > worry too much about it??
> > 
> > However, for sending text I recommend email.
> > 
> > Here's an idea for how a wiki in a world where spam didn't exist
> > could work:
> > 
> > You send email to an address. The text of the page at the path that
> > matches the subject of that email is then set to the body of the
> > email.
> > 
> > Whether that subject is "nice/orderly/unixy/path" or "Completely
> > bonkers with spaces that'll need to get percent-encoded and trunced
> > to match the 1024 limit."
> > 
> > If people want to edit they can paste the old text into their new
> > email.
> > 
> > This is just from the top of my head and not something I'd put into
> > production any time soon.
> >   
> 
> there is nothing preventing users to publish markdown files instead
> of gemini files. On gemini, it's not mandatory to have everything as 
> gemtext which would be reducing Gemini potential.
> 
> Like it is often done in gopher, people can have gemtext files as
> menus with their texts files in markdown that could be opened with a
> nice markdown viewer program, and links with gemini:// scheme from
> the markdown file would be opened using the gemini client. That would
> be like using opening a PDF from a website and clicking on a link in
> the PDF :)
> 
> The workflow may not seem optimal but it's perfectly doable with the 
> current state of the protocol.

Could also just use a different protocol for (complex) editing. Maybe
export the source files over 9P.

Link to individual message.

---

Previous Thread: [users][tech][ANN] rawnix.org gemini hosting and ESP8266 Gemini Server

Next Thread: How do get Gemini URL to appear in post?