Can you imagine what would have happened if the Hawaii message had happened in NYC or DC. The panic would have been unreal. People would have died. And the odds of a retaliatory strike would have been there too. This is how wars start, btw. #
Yesterday Mathew Ingram, a longtime friend and professional journalist, put out a call for feeds for a reboot of his use of RSS. #
This got me thinking. What if a community created such a list of feeds, and did it over a period of weeks or months, with discussion, and a certain amount of deliberation. #
We could use the tools of open source to do this project. #
So, I've set up a new GitHub repository where we can work on that list of feeds. I'll write a small piece of software that periodically turns that collection into an OPML file suitable for use in a feed reader. From there who knows what happens, but just getting a list of feeds for journalists to follow, collaboratively, while it doesn't involve much work or technical know-how, would be a major improvement over the way we all do this individually, for ourselves. #
Following up on yesterday's report on River5's file reading problem at startup, with futher thought I realized I did not have a solution to the problem. #
The way I proposed doing it yesterday would have resulted in just as many lost items at startup. The problem was that the central routine was sending the JSON text of the file to each of the callbacks. Each would then parse the text, producing a structure which it would then link into the cache. Only one of the structures would survive in the cache, the last one linked in, and it would have one of the new items. The other new items would be lost. In other words, no improvement.#
So I changed the code and had the central routine parse the text, and call each of the callbacks with the resulting structure. Now all the callbacks add their items to the same struct, (unless I'm still missing something) and the result is zero lost items.#
I've created a gist with the new code, and left the old gist in place. I have not yet released a version of River5 that uses this new approach. Testing it here first then thinking about how I want to deploy. #
Note this version is more complex because it has to initialize the struct once and only once, so the central routne, readRiverFile, must receive a callback that initializes the structure when the read fails, which it will do when the river file is first created.#
I haven't received any comments, but they are still welcome. #