| Thanks for the feedback. > 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]
it becomes |Placeholder text|[id text text/plain]
for regular text, and |Upload an image|[id other image/png]
e.g. for anything else by MIME Type.> 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.)