| > When designing that, it seemed simpler to allow the client and the server to manipulate the same URL data. 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.) |