- Gemini
- Spartan
- Scorpion
Gemini and Molerat use mandatory TLS. Scorpion uses optional TLS (with the same port number for TLS vs non-TLS, since the Client Hello message can always be distinguished from a valid request). Spartan has no TLS.
Gemini and Molerat do not use the userinfo component of the URL. Spartan allows it but has no way to send it to the server (why is that? That doesn't make sense to me). Scorpion allows the userinfo and if it is included, it can be sent to the server.
Molerat specification says that the fragment part of the URL is included in the request. However, I think that the fragment part would be for the client's use only.
Of the above, only Scorpion supports range requests (which are optional to implement); however, unlike HTTP, you can only specify a single range in a request (I think that specifying multiple ranges would overcomplicate it and isn't very useful anyways).
Gemini and Spartan do not include the length of the response, but Scorpion and Molerat do. However, the specification of Molerat is unclear if the length is mandatory or not. (In Scorpion it is optional, since the length might not be known by the server in the case of dynamic files.)
Molerat doesn't seems to have a way to send data with file formats other than Molerat forms (although it seems simple enough to extend the existing format), although Titan and Scorpion allow it. Spartan has no way to specify upload format either, and Spartan cannot distinguish zero-length uploads from a get request.
Molerat specification also doesn't seems to say if keys are case-sensitive or not (I guess that they are, but it is unclear).
Spartan also cannot distinguish query strings from uploads, although all of the other ones can distinguish it.
It also seem strange to me that although it uses a key/value list for responses instead of all on one line (the other protocols listed above do all use a single line for the status), that the "message" is used for purposes other than merely the message.
Molerat has a hash included in the response (although it is unclear if it is supposed to be mandatory or optional). Spartan and Gemini don't have any such thing. Scorpion has an optional "version code", although it is not used for caching; the version code is only used for handling edit conflicts, and optionally the client might compare the version code after making a range request to check if it needs to start over.
Molerat file format is more complicated than the others mentioned above and some parts are not entirely clear. It seems to be a superset of the features of Gemini. (Spartan also uses Gemini file format but adds an extra link type for requesting input.) (Scorpion uses a different file format; it (deliberately) does not have many of the features of Molerat format, but it does allow the possibility of specifying a different character encoding for each paragraph, and is designed to be easier to parse than Markdown and HTML.)
The example Molerat request in bash is wrong. The correct way would be:
echo -n $'get example.com/resource\r\n\r\n'
It seems to me that only Scorpion meets all three of these rules, while Gemini, Spartan, and Molerat, are only #2 and #3 but are not also #1.
I also think that it is useful for specifications to not themself require too many complicated specifications (including HTTP(S) and HTML) in order to be accessible. (For this reason, I wrote the Scorpion specification as a pure ASCII plain text document, which is the most portable kind of document file format. Fortunately, Gemini is also simple enough, but it requires TLS.)
Do you have any links to Scorpion? I'll keep looking but I haven't been able to turn up anything. I'm aware of the others you mentioned. Thanks!
It is also available by Fossil: http://zzo38computer.org/fossil/scorpion.ui/dir?ci=tip
It is also available by the Scorpion protocol itself at: scorpion://zzo38computer.org/specification.txt (Since you cannot read it without reading it to understand it first, here is a simple explanation: Use port 1517. Send R and then a space and then the full URL and then carriage return and line feed. Discard the first line of the result. Of course the specification is not actually that simple, but that is good enough to merely access one file.)
(I would like to know other people's comment of it if you have any)
> Molerat specification says that the fragment part of the URL is included in the request. However, I think that the fragment part would be for the client's use only.
When designing that, it seemed simpler to allow the client and the server to manipulate the same URL data. It's not really necessary, and if the client omits the fragment from the request it shouldn't affect anything.
> the specification of Molerat is unclear if the length is mandatory or not.
In Molerat, it is mandatory. In future versions of the spec I will probably change that.
> Molerat doesn't seems to have a way to send data with file formats other than Molerat forms
I have not included that functionality in the alpha version of the spec, but I think it should be relatively simple to extend forms to support it. Something like instead of
|Placeholder text|[id text]
|Placeholder text|[id text text/plain]
|Upload an image|[id other image/png]
> Molerat specification also doesn't seems to say if keys are case-sensitive or not
They are, I will make it more clear in the next version of the spec.
> It also seem strange to me ... that the "message" is used for purposes other than merely the message.
The message is modeled after the <META> field in Gemini. That being, that it can be exploited by the server to pass additional context to the client without having additional keys that the client must parse based on the response type.
> Molerat has a hash included in the response (although it is unclear if it is supposed to be mandatory or optional).
The hash is optional. It is intended to allow clients to perform aggressive caching if they so choose to. If a server is aware that a client supports it, the server can also use it to omit sending a response body entirely. I plan on adding a way for clients to optionally send a user-agent identifier to the server for cases like this.
> Molerat file format is more complicated than the others mentioned above
I aimed to create a markup language that was relatively simple to learn but expressive enough to allow a high ceiling of content variety- something beginner friendly that still allows for more competent authors to design what they have in mind.
> It seems to be a superset of the features of Gemini
mtxt is heavily inspired by both gemtext and markdown.
> The example Molerat request in bash is wrong.
Thanks for pointing that out, I'll make sure to fix it in the next version.
> MacWright's suggestions about a clean start for the web has three rules
I had not seen that article before, thanks for referring me to it. I agree that Molerat doesn't quite meet all three rules, but I am more interested in seeing Molerat live alongside the modern web anyways as a place to host blogs, documentation, and simple feeds (mailing list archives, microblogging platforms, etc.).
The specification is currently written in Markdown, I plan to rewrite it in mtxt once I get a good parser completed. mtxt is designed so that reading it as an ASCII plain text document does not lose or significantly obfuscate any meaning.
Currently, I am working on a Molerat client implementation (https://git.trinket.icu/molehole.git), and I'm using that to find the ugly kinks in my original draft so that I can write the second version of the specification with a more realistic idea of the implementation in mind.
It might be, although the URL will have to be parsed anyways to handle relative URLs, and removing # and whatever comes afterward is simple enough to do.
(The Scorpion specification (that I wrote) says that the fragment part is not sent to the server, and astroget does not send it to the server, although scorpiond doesn't care and will ignore the fragment part if it is present.)
> ... I think it should be relatively simple to extend forms to support it ...
That is not what I meant. I meant handling it in the protocol level, not in the form in the document file. What you specify wouldn't seem to work, because of the way that form fields are delimited in the protocol.
> The message is modeled after the <META> field in Gemini.
Yes, I thought that too, but using key/values and then still reusing the same keys for different purposes that are different from them, still looks strange to me.
(Similarly, I don't like that they used the "legendary" supertype in Magic: the Gathering to mean something else on instants/sorceries that is different than on permanents. However, it would make sense for the "ongoing" supertype to also suppress the state-based actions for sacrificing Sagas with too many counters, planeswalking from phenomena, battles with no counters dying, and the last room of dungeons; since, they are similar in that they do not apply if that object is the source of a triggered ability that has triggered but has not yet left the stack.)
> [The hash] is intended to allow clients to perform aggressive caching if they so choose to. If a server is aware that a client supports it, the server can also use it to omit sending a response body entirely.
It seems to me more complicated than it should be, but you can do that if you want to do, I suppose.
(I have made mine to use something similar but for a different purpose; not for caching but rather to handle edit conflicts. It can also be used if you make a range request, to know that the file has changed half way in between receiving it so you will have to try again.)
> I plan on adding a way for clients to optionally send a user-agent identifier to the server for cases like this.
Since there is a blank line after the request, it makes sense that headers can be added, like in HTTP. (However, it adds much of the complexity of HTTP, too.) (Using a user-agent identifier for that purpose doesn't seem to be a very good way of doing that either anyways, as far as I can tell)
> I aimed to create a markup language that was relatively simple to learn but expressive enough ...
I meant more complicated for the author of the client program, rather than for the author of the document. (I hoped that would be clear by the example I had given.)
> I am more interested in seeing Molerat live alongside the modern web anyways as a place to host blogs, documentation, and simple feeds (mailing list archives, microblogging platforms, etc.)
OK you can try that if you want to do, although in my opinion still Molerat is not as good as the others.
For some of these kind of simple feeds, NNTP might do, too.
> Currently, I am working on a Molerat client implementation, and I'm using that to find the ugly kinks in my original draft so that I can write the second version of the specification with a more realistic idea of the implementation in mind.
Yes, that might help. (The code of the implementation can also help in case of parts of the documentation which are unclear; I know that it helped me with other programs in this way too, to have both the documentation and the source code of an implementation. As you mention, it could also help with improving the specification.)