This has been on my mind for quite some time, but during an email reply to Adam Nemeth today, I found myself putting it into words I like. Jabber will not succeed outside geekdom by selling the IM part of XMPP. That's my gloom point of view. I think that XMPP can be pushed to the clients as an enabler, as infrastructure, on top of which you build several services, in particular notification, but in general a always-on-presence, that all the usual services (email, blogs, social networking sites) can leverage to make their own services better.
Clarification: it seems, reading the comments, that people think that I'm talking about Wikipedia and their choices. I'm not. I'm using Wikipedia as an example as how this system could work and the benefits. Now back to our regular program.... I've always had a love/hate relationship with Wikis. On one hand, I like the perceived easy updating with the direct access provided by those edit links on all the pages. But on the other hand, using a browser to drive the whole experience is a limiting factor.
ejabberd is getting better and better every day. You can look over the developments in the last 6 months following the Process One blog: Millions Users Instant Messaging;Building Large Scale AJAX Chat System;ejabberd roadmap updated;Introducing FlexArch;plugin-based publish and subscribe is a huge leap toward rich presence.The last one is the one. This will make it trivial (for those fortunate enough to be using a publish-subscribe-type system already as one of the tools in their business) to publish via XMPP business-side events, like blog posts, comments, uploaded photos, new classified ads in your area, job offers, and much much more.
Most of my time, I program inside async event loops like Danga::Socket or POE. Accessing DBI inside those loops is not a straight forward thing. Most solutions involve forking worker threads and using pipes to communicate between my script and those workers. There are a couple of components for POE that do most of the work out of the box, like POE::Component::EasyDBI, but still, it feels a lot like an hack.
In a project I was working on, I had some performance problems to startup a DBIx::Class schema with about 75 sources. It took about 19 seconds to startup. After a quick thread in the mailing list, the startup time is now 2 seconds. The two-part solution is this: move all your load_components() into a common class and use that class as the base for your sources;use the schema provided load_classes(), its very fast.
If you have Growl installed, and you use the Terminal.app a lot, then make sure you also install the growlnotify command line tool. This will allow you to send Growl notifications from the command line. The most useful script I have, that I use constantly is this: #!/bin/sh # # Runs script, and prints a notification with growl when it finishes # $* growlnotify -m "Script '$*' completed" -s "Background script notification" & My version is called n, just the single letter n.
Imagine this: you have a set of standards that have grown complex over time;people all around are using variations of the theme, simpler and effective;you decide that you should also simplify things on your side.what do you do?Of course! You set up six committees to simplify your protocols. Because we all know that committees and simplification come hand-in-hand, right?
I'm sick, I could not stop giggling with this. Fortunately I'm not alone.
Does this mean that they are bankrupt?
I'm enjoying my iGTD experience. I think there is a lot of good stuff in there, and with some MailActOn stuff and some mail rules, I've been able to use very effectively as a Inbox for everything. I still miss a easy way to track external tickets, but maybe we can work around that with the Pro version and some plugins. Update: Ok, found it! Just select all the projects... Stupid me.