💾 Archived View for bbs.geminispace.org › u › zzo38 › 20469 captured on 2024-12-17 at 15:28:02. Gemini links have been rewritten to link to archived content

View Raw

More Information

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

Comment by 🦂 zzo38

Re: "Thoughts about Scorpion & Scroll"

In: u/halscode

The design goals of Scorpion are mentioned in the FAQ sections near the end. Note that many of the features are optional (or are not applicable for some uses), so is not required to implement it (I tried to be clear which features are optional; if it is unclear then you can make suggestion to improve it). (This is also true of Gemini and Scroll; some features are optional there too.) Simplicity is one of them (it is especially meant to be simpler than the complicated mess of WWW), although there are certain balances that must be made; to avoid being too simple or too complicated and to consider which features are important vs which are not as important.

Although the file format of Scorpion is a binary format, this is meant to simplify parsing it rather than editing it (like I mentioned, there is the balance of what simplicity and minimalism something is; one thing will complicate another thing, etc). However, I did write a program that can create it from a text file (allowing conversion from other character encodings (such as EUC-JP and EUC-CN), and allowing preprocessing, and other features that do not appear in the output), so that is one way to make up such a file if you want to do. An editor could also be made, I suppose. Other ways would also be possible.

The use of the word "furigana" and of TRON character encoding does not mean that it can only be used with Japanese; it is meant to be usable for other languages as well (and there is some consideration for other languages too, e.g. text direction of Hebrew and Arabic text). And, I am not actually Japanese, but I know a few things about Japanese (which is why I used the word "furigana", and other considerations relating to Japanese). Furthermore, my opinion is that Unicode is messy and is rather complicated and not really that good anyways. (I also think that it is not appropriate to use one character set for everything; many people think they do but there is many reason why the requirements are different for different uses.) (Han unification is an actual criticism of Gemini that I had seen, although it is an uncommon one.)

About Scroll, note that I get a NXDOMAIN error when trying to access it directly, so I have read a archived version, which might not be the latest version. The archived version I have read does have a separate request for metadata/abstract, and that is something that Gopher+ also does. I also think the categorization of the pages like a library is also doesn't make much sense to me, either.

About "Astral Markdown", you can make up your own specification and then we can see what it is and we can make some comments about it. Since it is a file format, probably it can be used with any protocol that can use any file format (there are possibilities that it would do something unusual that make it difficult, but such a thing is unlikely), including Gemini, Scroll, Scorpion, and HTTP, although of course the specifications of those protocols do not expect clients to implement it, nevertheless it is possible to do so. (The optional conversion file feature of Scorpion makes it potentially possible that even a browser that does not understand Astral Markdown might nevertheless be able to display it anyways, although a browser might not support the conversion file, and even if it does, it will require the user to download and install (and possibly configure) the conversion file.)

About "Theme Packs", it is possible. We will see what you will write, and make a comment of it. (I had thought of something similar (including being able to apply to arbitrary directories), although the types of data being stored are different. However, an extension could be done, that multiple types of data are possible (including Theme Packs), as well as multiple protocols (possibly including alterate services for HTTP(S), e.g. so that Mastodon links can be supported without needing to implement JavaScript and HTML). Of course not all implementations would be required to support all extensions, anyways; these are all intended to be purely optional features, that, like you said, the user installs and sets up manually.)

🦂 zzo38

Oct 06 · 2 months ago

2 Later Comments ↓

🚀 clseibold · Oct 06 at 05:50:

I also want to clarify a few things about Scroll really quickly:

Hopefully that clears some things up. Thanks for looking into Scroll! :)

🚲 halscode [OP] · Oct 06 at 16:20:

@clseibold At the very least, you seem to understand how they work a lot better than I do! I do care a lot about accessibility, although it's usually not the first thing that comes to mind, and I'm also not nearly knowledgeable enough about it...

Original Post

🚲 halscode

Thoughts about Scorpion & Scroll — Scorpion First off I really don't like the use of a binary format. I see why you did it and I think it's too much. It requires a specialized tool to edit, so editing out of band via SSH, (S)FTP, or similar won't work. It's... well it is its own protocol, I guess. It has its own goals and if it achieves those, well that's great! Simplicity is obviously not one of them. The big ol' text file the spec is in is difficult for me to read. I think it's mostly...

💬 4 comments · 1 like · Oct 06 · 2 months ago