I want to change the URLs for the spec sections on the website from
<version>/<section>.html to <section>/<version>.html, to better reflect how we
do the versioning.
This puts each bit of spec in its own directory, updates the index to point to
the right place, and fixes continuserv to deal with directories as well as
files.
This will probably require fixes to the speculator too, but I'll have to come
back to that.
It's *definitely* not a client concern.
It isn't really in the right place at the moment, but s-s is very much a
work in progress whereas c-s is nearly stable.
Previously, all `m.room.*` events were wodged into `{{room_events}}` which
isn't great when you want to pull specific ones out. Batesian had a 1:1
mapping of `render_foo()` to a section `{{foo}}`, and having to constantly
add functions for new types is a PITA. Batesian now supports returning a
`dict` instead of a section `string` where the keys are the `{{foo}}` and
the value is what will be inserted. Also add conflicting section key checks
to avoid multiple definitions of the same `{{foo}}`. Define dicts for
event schemata and swagger HTTP APIs.
Using this new feature, split out the instant messaging stuff from the events
section, and replace `{{room_events}}` with a list of specific events e.g.
`{{m_room_member_event}}`.
Templates don't know at what level they will be inserted. Previously, we
hard-coded the title style which is not compatible with the build target
system. Define a set of styles which will be replaced by the gendoc script
when it encounters them:
'<' : Make this title a sub-heading
'/' : Make this title a heading at the same level
'>' : Make this title a super-heading
The build target system is now basically complete and functioning.
This will allow us to programatically position .rst snippets *anywhere*
which will for once and for all remove the horrid title level mismatch bugs.
We require this in order to allow people to re-shuffle the spec without
having to adjust the spec itself (e.g. 2 targets with different levels of
nesting).
We're well beyond the point now where a simple `cat` of .rst files to "build"
the spec is practical. We may want to slice and dice the spec in different
ways to address various cross-cutting concerns. To this end, there is now a
'targets' file which contains the "build targets" for the spec, which contains
the sorting order for the .rst files. For now, we just have a single
target: 'main'.
Mark Haines