Yep! This would be fun.
Conversation
What we're running into here is a need for a multi-architecture publishing: books, blogs, wikis, threads, and my latest obsession, short glossary-like log-level entries. Kinda like Intel's OneAPI is trying to make a single interface for many architectures. software.intel.com/en-us/oneapi
1
4
Yeah - aligns with the "headless CMS" idea except that world is deficient in imagination. It's not headless CMS so that you can reskin the front end it's headless cms so you can merge blogs, books, wikis, threads, roam etc
1
2
unfortunately, all this is technically way beyond me to set up on an experimental basis so I'd need someone to invent a scheme basically. Until then, I'm sitting around in wordpress.
1
1
The one thing I'd add to this vision is a politics... I'm old fashioned enough to think that the successor to blogging should be an open standard that multiple products could meet rather than a single product (no matter how well executed)
1
2
Technically, we seem to be poised at a sort of "big data" moment for content. 10 years ago, if I had posed the problem above, people would have said "drupal with a lot of custom node models". Now that seems like far too heavyweight approach and exactly the wrong direction.
2
2
A sort of nosql approach... platform independent content-centric networking. Content nuggets that can live in a big data lake (=domain) and sustain a consumption "ship" sailing around on it. A better client, not a better server. Browser 2.0 that's aware of content architecture.
2
3
static page paradigm already unbundles the backend and JIT compiles it to browser front-end. What we need is a way to intercept that process with domain-level information architecture cc
ribbonfarm should be a set of pipe logic rules, not a server db and a skin
3
3
To do this properly, you end up having to throw away so many comforting abstractions, like even the notion of a "site" goes away if it's truly content-centric.
1
This poses a problem for the notion of a static site generator!
1
well, it's a start. The "site" the domain maps to can simply be a browser-readable map of stuff strewn about the web that has a sort of soft DNS lookup, where domain-name URL is kinda like a content-addressing hash rather than a location pointer


