(No, there's still no activitypub, but that's not a superbig priority as at the end of the day, that's just sending and receiving JSON requests which isn't much different than recieiving them in the command line.)

I really have basically just built a MUD engine, minus the ticking services and user authentication/profiles.

I haven't in a bit so let me explain an object: it's a hashtable with three hashtables itself: one for its headers (metainformation about the object, not really used right now,) one for its data: the teraum-project object will have data like project-name, object-title, so on, and the third hashtable is for renderings: each time the object gets rendered as a given form, it gets put into that hashtable. forms are functions that take in an object and return out a string: for example the text-project-brief form takes in an object and spits out the text "{{project-name}} is {{project-description}}."

Each function that works with an object should make a copy of it and work on that and return that, leaving the original object unchanged - fuck side-effects.

So written out, an object near the tail end of its processing - its been made-up and rendered into all its forms, might look something like this: (ht (:headers (empty-hash-table)) (:data (:object-language-code "en") (:object-author "emsenn") (:object-title "Teraum") (:object-description "Teraum is a a tragically funny fantasy setting.") (:project-title "Teraum") (:project-description "a tragically funny fantasy setting.")) (:renderings (:text-project-brief "Teraum is a tragically funny fantasy setting.") (:text-object "TERAUM\nby emsenn\n\nTeraum is a tragically funny fantasy setting.")))

So I've churned all the code over again.

Well, not all of it, but a fair chunk- I'm trying to get the "take a request and process it properly" process down before moving on.

I think I'm going to have a list of objectmakers, like I do now, but each has a few keys, not just is a value - not just a "take an object and make it into the thing," but "here's a string, give me an object" or "here's a symbol, give me an object" or "give me a list of all strings/symbols you know about"

Right now I have an elisp "package" called "ems-library" that's its own datastructure. I can write three functions that perform the above (or well, two, since there's no symbols to look up) and then add those... well okay now my cat's meowing and I can't keep a train of thought

I can add those functions as the values to the keys mentioned above, in a table, and then requests can have not just the symbol but which key in the table to look up.

(I expect this to be gibberish to anyone reading... especially toward the end because my partner was harassing our cat so I had both baby talk and meowing happening like two feet from my head.)

truly awful

So, update, but I'm renaming it "ros" instead of "suros" because I realized that there's no real concept of "user," it's just a responsive object server. So my implementation of a ros (gross without the g) is ems-ros.el

(Isn't early alpha Fun?*) (*Fun in the dwarf fortress sense, which I was going to link to an explanation of but am not finding one: it's basically poking fun at mistaking difficulty and lack of understanding as being "fun." It's... not.)

Y'know a really nice quality of life extension for Emacs? centered-cursor-mode

Especially on my tall screen.

The six steps from receiving a request to sending a response are

1. the ros reads the request
2. the ros passes on the relevant information to the relevant object maker.
3. that objectmaker returns a "rosian object," a table of headers, data, and rendered forms. at this point the object might have some headers and will have some data.
4. the ros passes that made object to an object former.
5. the object former renders some stuff based on the object's data and headers and hands it back to the ros
6. the ros sends the formed information back to the request