H&D website v2 working notes: Difference between revisions
No edit summary |
mNo edit summary |
||
Line 22: | Line 22: | ||
Some work needs to be done to figure out how this must be setup, but should be fairly ‘standard’ procedures. | Some work needs to be done to figure out how this must be setup, but should be fairly ‘standard’ procedures. | ||
H 10-12: Great idea. Static site would also greatly speed up the site, so that's a nice bonus of this workflow. I would like to note that | H 10-12: Great idea. Static site would also greatly speed up the site, so that's a nice bonus of this workflow. I would like to note that adding a page would potentially affect a lot of other pages through navigation etc. So it would probably be more effective to regenerate the whole site on changes (or at least when a new page is added). We'd have to implement some sort of debouncing to prevent doing that too often. |
Revision as of 11:55, 10 December 2020
wip how to structure notes:
- do we need dates? could we use article's changes timestamp and diff to get this?
- maybe better organize around software "feature" / areas of work?
2020-12-09
Recent changes stream
As part of the new website implementation, an idea would be to send to the python frontend application a “message“, whenever a change has been made to the wiki. The reason for this, is to use the python app to fetch the page which has been modified, and save it to disk as a static HTML file. All in all, the python app should act as a bridge between the dynamic wiki content and the static output that we use to serve the final website.
A first idea was to make a user bot, that would subscribe to every page in the wiki, would follow their changes, and once a page would change, a notification was sent to the bot (unclear if in an internal message format or through email). After this happened, the python app would use this email to fetch the latest version of the changed article, and lastly would produced a static version of that page.
A better, more fitting option though, is to use Recent changes stream APIs, which just does this: listen to any change for any page, and send that event to some other server. The $wgRCFeeds handles the setup for this, and once the python app runs as a server, we can either use UDP or Redis to subscribe to this stream.
Some work needs to be done to figure out how this must be setup, but should be fairly ‘standard’ procedures.
H 10-12: Great idea. Static site would also greatly speed up the site, so that's a nice bonus of this workflow. I would like to note that adding a page would potentially affect a lot of other pages through navigation etc. So it would probably be more effective to regenerate the whole site on changes (or at least when a new page is added). We'd have to implement some sort of debouncing to prevent doing that too often.