💾 Archived View for bbs.geminispace.org › s › Scorpion › 19729 captured on 2024-12-17 at 15:04:37. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Scorpion protocol/file-format
If someone else try to make implementation too then it may be better possible to see if there are problems with the specification, e.g. if something is confusing or unclear or wrong.
(I may also try to make my own multi-protocol browser (including Gemini), although that might takes some time, especially if I should need to figure out what data structures and other stuff to use in the implementation)
Protocol specification on GitHub
Specification link (using Scorpion protocol)
Sep 19 · 3 months ago
💎 istvan · Sep 19 at 05:19:
You should include a link to the protocol specification.
🦂 zzo38 [OP/mod] · Sep 19 at 05:24:
OK, now I did
💎 istvan · Sep 19 at 05:58:
Thanks. That's going to help a lot of other people on BBS who might be interested in your protocol.
Implementation of TLS is optional but is recommended; implementation of non-TLS is mandatory if it is possible.
You've made both TLS and non-TLS optional?
This means I can write a program that does nothing and say it fully supports scorpion protocol because non-TLS was impossible for (insert excuse here).
World language is essential to *all* my use cases: I don't generally dig into any protocols that are ASCII only and do not support (at the very least) extended Latin characters or Chinese.
Will let other people who are more likely to be interested in this protocol dig into the rest.
🦂 zzo38 [OP/mod] · Sep 19 at 06:19:
Thank you for your comments.
You've made both TLS and non-TLS optional?
This means I can write a program that does nothing and say it fully supports scorpion protocol because non-TLS was impossible for (insert excuse here).
It is clearly not what I meant. I will try to fix the specification to make it more clear what I meant.
It is unlikely that there is a good excuse for non-TLS to be impossible (if you have some real ones, I could mention those in the FAQ, perhaps), so I just deleted "if it is possible".
World language is essential to *all* my use cases: I don't generally dig into any protocols that are ASCII only and do not support (at the very least) extended Latin characters or Chinese.
Although the protocol uses ASCII characters, this does not mean that files, documents, etc cannot use non-ASCII characters. (This is the same with Spartan, which does not require documents to be ASCII only (and even specifically says they aren't), even though the protocol is ASCII. I have seen that some people were confused about this with Spartan too, even though I did not write the Spartan specification.)
Documents can contain extended Latin characters and Chinese characters (as well as Japanese, etc).
The FAQ (near the end of the document) mentions this too. (Maybe, I should mention at the top of the document, that there is a FAQ section near the end.)
💎 istvan · Sep 19 at 07:04:
It is clearly not what I meant. I will try to fix the specification to make it more clear what I meant.
I know exactly there is no way you meant that. I was just pointing out it’s a problem it can even be read that way.
Specs are all about being precise. Anywhere you leave an opening on a critical function is where you run into trouble with people designing for incompatible implementations.
It is unlikely that there is a good excuse for non-TLS to be impossible (if you have some real ones, I could mention those in the FAQ, perhaps), so I just deleted "if it is possible".
I can’t think of any real excuse. Your solution to delete it is the best idea!
💎 istvan · Sep 19 at 07:12:
Although the protocol uses ASCII characters, this does not mean that files, documents, etc cannot use non-ASCII characters.
Is a client expected to display non-ASCII text? This is one of the issues with gopher.
I have seen that some people were confused about this with Spartan too, even though I did not write the Spartan specification.)
I was certainly confused about this. The way spartan presented itself it sounded like gopher.
The FAQ (near the end of the document) mentions this too. (Maybe, I should mention at the top of the document, that there is a FAQ section near the end.)
Not a bad idea. It might be worth clarifying somehow earlier in the document too.
🦂 zzo38 [OP/mod] · Sep 19 at 23:31:
I was just pointing out it's a problem it can even be read that way.
Yes, and thank you for mentioning that problem, so that I could correct it.
Is a client expected to display non-ASCII text? This is one of the issues with gopher.
Yes, although some clients might not be able to display all characters (e.g. due to a lack of suitable fonts, or displaying using a format (e.g. a terminal emulator, or a limited display hardware) that does not support all of the characters, or a computer with limited memory or disk space, etc). (This is true with other file formats too, including Gemini and HTML.) An implementation that allows users to install additional fonts would be helpful in case they want to display additional character sets.
The GitHub repository includes some bitmap fonts, for PC character set and for TRON plane 0x21 (which includes JIS X 0208, JIS X 0212, JIS X 0213, GB 2312, KS X 1001, 6-dot Braille, and 8-dot Braille). If necessary, program to convert the fonts may be written, or they can be used as is. Making and using additional fonts may also be possible, and in future more may be added too.
It might be worth clarifying somehow earlier in the document too.
OK, I did that too.
🦂 zzo38 [OP/mod] · Sep 26 at 23:43:
I had also posted a feature request on GitHub for Lagrange and for elinks.