Journal : 2024-05-12

NEXT - paths for entry pages/fix errors in PostCraftPrep - can refactor to simplify? check s:ConfigMap

#RELOCATE transmissions topology - multiple lists, series/parallel

support-it@blackview.it

Progress on Postcraft! I believe I've got s:Unfork working. I made a s:Fork to test it in isolation with a little test application. Fork/Unfork aren't very good names, something a like Multicast might be better. Leave that for the Great Refactoring, which I'm do some time after #Postcraft is up and running.

It's funny, while I was trying to figure that out, the thought of providing something like a GOTO service crossed my mind. There is a natural progression from pipeline to flowchart-shaped structures, to a little language (with Turtle syntax!). But I have to invoke YAGNI here. It will be interesting to see what other steps in that direction I have to take, but the goal right now is to make it easy to get things done. And get them done.

Oops...I forgot I need to do generate the final entry pages next, before Unforking.

#RELOCATE pc:ContentGroup might be better as a more general trm:Group

to add s:Unfork after the entry content generation phase, then

Yesterday I said : Ok, for TODOs, I'll have a top-level todo/index.md file, plus monthly files like todo/2024-05.md. Then have Plan blocks in this journal for daily bits.

What I've got dangling, I'm not sure how best to manage. It would be good to have a Where I'm At Status somewhere. And a Requirements. And a convention for flagging doc chacteristics in terms of changeability.

Note to #RELOCATE, re. #GTD : I need to be clearer in demarcating my planning activity and the actual work. I'm revising too much when I hit the code. I need clear plans written down before I start, no matter how long they take. Then code faster.

context.entryContentToPage = { sourceDir: sourceDir, targetDir: targetDir, templateFilename: templateFilename

Plan

Bergi 'Unified Landscape'

Phone Return!!!

Postcraft

Fork is more like multicast - rename?

Kaggle-Preferences

  • get set up, run the demo

FOAF-Archive

  • Placeholders + a:manifest for FOAF-Archive
  • FOAF video

Unfork

Ok, the Topology question. Postcraft is quite a good example on which to be thinking about this.

  • Phase One : Markdown -> HTML at raw entry level, then raw entries -> final entry pages
  • Phase Two : raw entries -> front page etc.

Phase One forks into multiple processing paths, one for each markdown file. To avoid uneccessary complications, it makes sense to make sure Phase One has completed before starting Phase Two. So,

I believe how I've got s:DirWalker means that order is maintained subsequently, even though each path runs independently (parallelism for efficiency isn't something I need to think about now).

  • three semi-independent pipelines defined in transmission.ttl : markdown -> HTML rawEntries; rawEntries -> entries; rawEntries -> front page
  • one 'continuous', with an Unfork or some such to bring the control flow down to one path
  • one more blocky, with ContentGroups being set up from manifest.ttl in ConfigMap at the start

All three approaches could be supported, but for now I should just pick the one that seems most suitable for the current task. Considerations :

  • keeping it simple, with sensible defaults
  • keeping concerns separate :
    • transmission.ttl = topology
    • services.ttl = details of individual service configurations together they define the application
    • manifest.ttl = application instance configuration

I need some fresh air.

Journal : 2024-05-12