Journal : 2024-05-11

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.

Plan

Bergi 'Unified Landscape'

Phone Return!!!

Postcraft

  • **** s:Unfork - write a little test application (already got?)
  • write a little test application t:transmission (already got?)

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.

Kaggle-Preferences

  • get set up, run the demo

Journal : 2024-05-11