Nice catch! It probably would be good to switch to an IDENTITY column, but it shouldn't make too much of a difference because Chela manages the state of the index manually anyways.
In order to create new IDs it consumes the next value of the index column, and then manually sets the index and the ID in one go.
> 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.
> 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.)
I gave it a try and it does exactly what I would expect from a link archiver.
As others have mentioned, being able to store offline versions of pages would be nice, but for me personally it's not a deal-breaker.
My day one syllabus as I have it planned is going to focus on programming as a method of breaking problems into smaller problems that can be fed to the computer.
I plan to cover variables and if statements as well as operators within both of those.
These tips will be super useful, as I have been worried I'll move too fast for students to keep up with, and nothing is worse than the frustrating feeling of not understanding what's going on but wanting to.
I'm honestly never sure how to feel about these things.
One the one hand, this is incredible, it's the future, and it's the sort of thing I would read about in sci-fi books as a kid and go "There's no way I'm alive to see this sort of thing for myself."
But on the other, I can't help but feel like this is diluting the spirit of creativity. I've done a little bit of toying around with ml, and I'm not sure I consider a probability network like that a real source of creativity.
And finally, the fact that this book is being monetized doesn't sit with me well. The characters are public domain, and the prompter has every right to do this, it just makes me feel bad for authors in the future. It's probably about to get even harder to publish a book from here on out.
I wonder it's because there's so many Windows users, so few Linux users, and that middle-but-still-reall-small number of Mac users that it seems like a good market to enter into. On Windows there's likely an overwhelming amount of new products for the platform, on Linux there's not enough people willing to try your product for it to be worth the dev time, and on Mac it's still small, but who knows plenty of apps are Mac-only and they seem to be doing fine.
Also, it's probably easier to develop for a *nix platform since it's more open than DOS.
Sources: Just speculating, I can't back anything up 100%
I'm not super knowledgeable on how DNS systems work. I'm confused about how it can be a one time payment and still be owned by you without a registrar billing you yearly to keep it?
This is maybe my favorite application of GTP3-type AI yet! The results were very quick, charming, and on point. I tried it out and was honestly really happy with the gift recommendations (I said I had a small budget for a friend who was into art and fairies and it suggested a small notebook with a magical creature cover and some colored pencils).
Some criticisms that come to mind however, is the UI. Viewing the website in Safari and in Chrome, there's a bar that runs vertically between the text and input box and then along the bottom of the page that is really unpleasant to see. Also maybe centering the input box would be a bit nicer, I felt a little weird gluing my eyes to the right of my screen when all the catchy glowing text and emojis are on the left.
Overall, super cool project and fun application of GTP3 that I wholeheartedly approve of. Projects like these are why people like me get inspired to learn programming in the first place.
In order to create new IDs it consumes the next value of the index column, and then manually sets the index and the ID in one go.