An Emergency Broadcast System for Twitter might look like this.
When everything is working at Twitter, all the clients communicate through Twitter. A client is an app like Tweetdeck, UberTwitter, Seesmic, Brizzly, Tweedroid, etc.
However, when Twitter is down, each client sends your tweets to a "safe place" and the clients your friends use hear about your status updates from there.
There's still a lot of disruption, but some messages get through. Over time the EBS will get better, as we learn better how to make the best of a Twitter outage.
Reality: We still need to communicate even when Twitter is down.
Bottom-line: The client vendors are key.
Chris Janton pointed out that some of my OPML isn't properly handled by another OPML-processing application, and that my own validator rejects it as invalid.
Here's an example of a file that's rejected as invalid. It says: "The type attribute on an <outline> element should be a known type."
But the OPML 2.0 spec says this is okay. "OPML can also be extended by the addition of new values for the type attribute."
The reason it is this way is that the OPML Editor, the app that OPML is the file format for, has an extension mechanism that allows this. When I give an <outline> element a type attribute with a value of foo, when the user double-clicks on that element, the editor looks for a nodetype definition called foo. If it has a method for handling a double-click, it gets control, does its thing, and returns, overriding the default functionality. It's essential to the way the editor works that the type attribute be allowed to have unforseen values.
So it's clearly a bug that the OPML Validator rejects these OPML docs.
Not sure what the OPML-processing app should do, I'd have to know more about what the concern is. But the spec clearly allows what we're doing with Scripting2's OPML.
Like almost everyone else, I have been unable to get through to the Apple Store on the web. I had the time today so I got on the subway and headed uptown to the Apple Store on 5th Ave, thinking I could order it there, in person.
At first, the salespeople said I had to do it the same way I'd do it from home. I said that doesn't work. They shrugged it off. I was getting ready to leave, but on the way out I asked another sales person, and really pressed, and he said he could reserve one for me to pick up on the 24th. Sheez, why didn't you say that in the first place? Never mind. I did it, and now presumably I'll get one on the 24th like all the other Apple-addicts who can't wait to get their hands on the latest and greatest.
I wanted to get this out there, in case you're near an Apple Store, you might want to go down there, and tell them you know you can reserve one for pickup on the 24th. Tell them Dave toldja. ">
Just as a program has source code, so does the writing on this blog.
It's always been this way, but I've accepted the limits of other blogging tools, and the limits of RSS, and not exposed the richer writing environment behind scripting.com. That is changing, gradually, with the new software.
The small initial changes have caused some consternation. Some people are concerned that they're not getting all the content in the RSS feeds. Some people feel the plus sign is too small, and others don't want to click on it, they think it should be expanded by default.
So here are some responses to these concerns.
I want to include all the content in the feeds, and with a change I made last night, I now am. I'm just not providing it in the old "flat" way. There's a link to the source code behind the HTML rendering. The source has all the text. Of course there aren't any apps that read this format, yet. It's always that way. When I first came out with the predecessor to RSS, no one read it. But eventually someone did, and then a lot of people, etc etc. That may not happen here, but then again, it might. Don't count it out.
There are actually now two ways to get the source behind the HTML rendering: 1. You can get it from a link element in the HTML. This would be useful for a bookmarklet that wanted to try alternate rendering of the text, as Readability does, for example. 2. It's in the RSS feed for scripting.com. Each item links to the source in a new element called <scripting2:source>. This would be used by a news reader app like Google Reader, if they wanted to do something special with content coming from advanced blogs like Scripting News. Do I believe that eventually the other blogging tools will offer this? Yes, in fact, I do. Do I think Google will support it now? No, as long as it's just my blog, they won't support it (probably). But when others do it, they hopefully will decide to support it, and help us add some cool features to the web. I would, of course, like to see them do that.
I also made a small change to the rendering of the site. There's now a small XML icon below the blogroll, in the right margin of every page. It links to the OPML for the blogroll. I expect there will be some interesting things doen with that. There are features already implemented in the blogroll that aren't yet visible in the UI. I think the blogroll will eventually bust out of the right margin and become something itneresting on its own. ">
There have been some excellent suggestions about the sub-text feature: 1. Make the icon larger. (Will do.) 2. Move the icon so it's at the right and bottom. (Makes sense, but isn't the way outliners work. I'm going to stick with the current placement for now.) 3. Make it so clicking in the text makes it expand. (Good idea, but doesn't that break selection? What if you want to copy a bit of text from the post?)
Finally, I'm really glad this discussion is taking place here now. I wanted to draw intelligent thoughtful technical people back to Scripting News, to participate in what I hope will be a bootstrap of some new technology. Keep discussing, share your ideas, even if you don't like what I'm doing. There's more to come. Sometimes the first few chapters of a story don't make you happy, then you see where the plot is going, and it starts to make sense. ">