The Mozilla link toolbar doesn’t work as well as Firefox’s link toolbar extension does. For about a year now I’ve had
rel="bookmark" on the permanent links to my posts, and these have quite merrily appeared in Firefox’s link toolbar, and I’ve just added
rel="section" to links to my monthly archives, and these also appear nicely
But neither of these appear as menu options in Mozilla 1.7b (build 2004031616 if you care). Rubbish!
In the Dashboard architecture, cluepackets are used to send messages between front and back-end applications. Now what if there was a way to tunnel cluepackets through Jabber? Has someone explored this already?
It would be trivial to embed a jabber client core into an application which sends Cluepackets to a transport which then does all the work.
But of course your frontend needs to actually be able to send the cluepackets in the first place, which for the majority of Windows applications, just ain’t gonna happen.
I actually tried writing an Jabber cluepacketer (for want of a better word) a couple of months ago, but I didn’t have access to a GNOME box and didn’t find the cluepacket doc that Leigh links to (which is very useful – I’d been trying to read the C source to see what the structure should look like! Looking around now I suddenly find things like a useful wiki page about CluePackets but I swear it wasn’t there before! 🙂 ).
DJ Adams (author of Programming Jabber and any number of introductory Jabber articles) hints that using the Publish-Subscribe mechanism of Jabber (JEP-0060 for those who care) would be the most interesting thing to do, but quite frankly, it also looks like it would be the hardest thing to do. 🙂
Looking around, there are already some interesting frontends, including one for Firefox/Mozilla (there are some good links to other Dashboard docs on the same site).
Maybe I should reinstall my linux box at home, follow the Getting dashboard Running instructions and see how it goes. Is it worth it?
The Dashboard lxr is currently offline so instead the docs are available on this URL, which I expect to become redundant as soon as the Dashboard lxr comes back online. 🙂
I don’t pretend to be a DBA but currently at work that’s part of my role (what was that sa password again?).
Anyway, the Java Performance Tuning website has a recent Question of the Month which just happens to deal with primary key efficiency in SQL Server – well worth a read.
I was all set to write a post about how we should be using centralised apps with XUL frontends for aggregation to provide native interfaces regardless of location but I find that Manuzhai beat me to it
I think an online XUL aggregator is perfect: a rich UI, but available from anywhere in the world.
He mentions XUL Channels which is no longer available because of hosting problems, and it’s certainly a start (the source is available and took me a grand total 2 minutes to set up). It’s missing a host of features such as multiple users, read/unread items, flagging, Atom supoprt etc. but given that the code alone is six months old this is probably fair enough.
Presumably with a bit of hacking it would be possible to make this an executable app (loading it via the chrome:// command like ChatZilla). It could also read any feeds for which an RDF transformation is available, and the missing features don’t seem like they’d be that hard to add in – XUL’s a doddle after all 😉
The hardest part would probably be dealing with HTML entities, which it currently appears to struggle with, but they could always be stripped out in the first instace. Do I smell the future burning bright?
Simon writes about the legion of non-HTML text markup languages and introduces his own (we have enough. please stop now. Maybe writing your own markup language is the new “writing your own wiki“, which was the new “writing your own aggregator” ?)
Anyway, he points out that anyone entering italic*italic-boldbold* into most engines
and that includes Markdown, Textile and [his] home-rolled Python solution… will output vadly (sic) formed XHTML.
I’m glad to be able to say that JTextile gets it right, producing:
It still doesn’t do normal line-breaks, but hey, nothing’s perfect. 😉
G fixed the linebreak problem at long last. Stupid StringTokenizer 🙂
Manuzhai emails to tell me that FeedDemon doesn’t actually support Atom yet, so my last plea is futile.
He points to a coverter which produces an RSS 2.0 feed from my Atom feed.
There’s also a converter which will produce an RSS 1.0 feed from my Atom feed (which I actually linked to back in February), so FeedDemon users need not despair!