In my perpetual reshuffling of home projects, I need to bump up rig4j, and abandon rig4r.

Rig4r: It was somewhat useful to learn Rust lang. However I really don’t care much about it. That language does not solve any problem that I don’t really have.

That said, it wasn’t a complete loss. The rig4r project showed me there’s some value in splitting rig4 in a gdoc-downloader vs a generator.

In the current train site+blog, a simple blog update results in a 6-7 minutes rig4j run time.

90% of that time is in checking images/graphics have not changed -- it takes about forever to pull them off gdoc using the current gdoc API… this will get addressed whenever I focus on rig4j again and implement the caching I specified from the start yet never fully implemented yet.

It’s also worth noting that the current rig4j is really “0.1-exp”.  There would be some value in taking the learnings from that experiment -- what worked well, what did not work --, cross-reference that with the initial spec, and maybe re-implement from there.

The main pain point is looking up all these gdoc images instead of relying on cached blobs.

The second pain point is the HTML exported by gdoc. I have it somewhat cleaned up, yet I think even more could be done. On one hand I’d like to strip it down as much as I can to the level of what is/was supported by izumi’s syntax, and on the other hand I’d like to retain some complex elements such as tables.