Video or it didn't happen

I've made a screencast to show some functionality that PubSubClient provides. Doesn't play in SWFDec at the moment, so you might have to use something like this. I accept Google Video's terms of use, but not YouTube's.

The video shows the Browser test application being used to find the nodes on a server and their sub-nodes, add and delete nodes, and add and remove node owners. I've been busy tonight, so that the display issues which cause me to close and reopen windows to show updates are fixed, I've got the Owners functionality working for Publishers and Outcasts too, and I'm mulling over a Subscriptions tab in the node properties (awkward since it may involve message stanzas, not just iq stanzas), generating the contents of the Metadata tab dynamically based on what's defined and changing the access model and other configuration options (awkward since it involves requesting, submitting and cancelling XMPP forms).

For now though, I'm getting tired so it'll have to wait.

Ugly Mug

I'm a little vexed at the current implementation of the Mugshot client side application. The idea of Mugshot is to collect together as much of one's online activity as sensible into one place, then provide software and APIs to allow desktop applications to access online services and online services to access desktop applications. This is a good idea, I think, and I certainly prefer it to the whole browser-based mentality (Flash-based video players suck balls! They seriously do! Aside from the obvious proprietaryness they're slow, clunky, crash-prone, ugly, completely inaccessible and detached from the rest of the system and everybody keeps reinventing the wheel and making a load of 75% usable apps rather than working on the remaining 25%. Media players have been around for AGES, why not extend them to use online features? Windows Media Player has been doing this for ages (honestly it has. Just because nobody with half a braincell lets Windows Media Player through their firewall doesn't mean it *can't* open 5 Idiot Exploiter windows to the same gay porn site when attempting to find a codec for an Amiga conference video) and iTunes is an example of a player that does this in a way that people use, and of course there are those options for people with better things to do than suck collective corporate cock like Rhythmbox, Amarok, Banshee, etc. The "But it STREAMS!" argument doesn't hold water since we've had the likes of Real doing that on the desktop since before the last great realisation that the web isn't as orgasm-inducing as those with an agenda to sell promised. And as for embedding desktop media players inside a web browser... Gah, I give up on those people!). So, the problem with Mugshot? Well, like many Konqueror users will appreciate, it makes heavy use of Firefox. Now, despite what Microsoft might tell you, Firefox is not part of the GNU/Linux desktop (unlike Idiot Exploiter 7, which IS an integral part of Windows Vista (Note to self: Never contradict anything used in court as evidence to clear my name) and should therefore have all of its various bugs bundled together as part of Vista's!). Of course it *can* be, and usually is, but the two most ubiquitous desktop systems used on top of Linux are GNOME (with its Epiphany browser (which I use)), and KDE with its Konqueror browser, and therefore Firefox is always an add-on. Many Free Software distributors bundle Firefox with their systems by default, but they are still adding it themselves.

The problem I have at the moment is one of standardisation. There is a significant lack of cross-application APIs for high level stuff that users might give a crap about. Dbus is obviously a step in the right direction in this regard. I know, I know, but DCOP sucked precisely *because* it was part of KDE. Like Artsd. All of those petty squabbles were bound to split development into an us-and-them scenario, and along the way create different implementations of one-to-rule-them-all technologies (like inter-process communication buses and audio mixing servers (NOTE: I heard great thinks about PulseAudio on the Ubuntu development Wiki a while ago. I installed every PulseAudio package I could find in Ubuntu and guess what? I instantly lost all sound, applications refused to start due to no available audio channels, I ended up trying countless media players to watch Click because the lack of audio made me think it was a codec issue, etc. Know what fixed the issues *every* time? "killall pulseaudio". I just ended up uninstalling it (and when I shutdown I was shocked by the logout sound, which I forgot existed!))). Developers are finally starting to realise that there is more than their own little desktop niche out there, and the GNOME/KDE fanboism has cooled down somewhat recently (at least among developers) which has lead to more exploration of mash-up desktop systems based on "I like this program" and "This program does what I need/want" rather than "Well, at least it works without having to run 30 weird commands". Of course now that the lack-of-integrated-applications barrier to entry is dissolving more desktop systems are being created as a result (XFCE seems like quite a popular GTK alternative to GNOME these days, but I could never get used to the way its panels work. Of course the GTK bit is still an unfortunate artifact of the Free desktop's genesis, I shouldn't have to give a crap about what GTK and QT are). Personally I think the ever-increasing use of Freedesktop.org as an us-and-them Switzerland is also a boon. In my opinion visiting Freedesktop.org should be the first step in creating a desktop application/technology. Backend developers (things like Dbus) can check for any projects which do a similar job, and if they exist either extend it, fork it, create and register a new system with a compatible API, gouge out a more fundamental backend from the existing code and make a new project which abstracts itself, along with the gutted existing implemetation, on top of this new backend, whatever. Application developers can do the same thing, but focus more on the API stuff (backends with compatible APIs can usually be directly compared in different scenarios, since the implementation is hidden (that's the point) and the most efficient for a given limit can be used. Applications which are directly interacted with, however, is entirely up to preference. I am not saying one-messaging-client-to-rule-them-all, I am saying using the messenger you prefer should not be restricted by integration/basic features/etc., just like Miranda vs. Pidgin vs. Adium comes completely down to preference, as they all use libpurple as a backend and thus have the same capabilities (of course that particular example is complete bollocks as Miranda uses Windows's graphics toolkit and runs on Windows, Adium uses the Cocoa implementation of OpenSTEP and runs on OSX and Pidgin uses the GIMP ToolKit and runs on the various systems that GTK supports). With every popular project following the development of neighbouring technologies far more time could be spent doing cool stuff rather than reimplementing things which already exist, users could switch between different applications that do the same job without worrying about configuration or setup, because the backends would be the same (and if work is structured like this and more cool features and experimental ideas are tried then switching back and forth between applications is a must if anyone is going to bother trying all of these new features).

KDE4 looked like it was going to play fair with the stardardisation idea, but instead they seem to have gone for another custom layer of abstraction, this time on top of those that already exist making KDE apps capable of using the existing standards, but making KDE standards inaccessible to external software (eg. why does Decibel exist? It just does the same job as Telepathy as far as I can tell, but adds another layer on top of it. Of course I am no expert in this area, but if it does do something new then why make it part of KDE rather than as a separate project with its own merits? If I want to make an application which uses it users will need to install vast chunks of KDE to run Decibel to run my application, which shouldn't be needed). Plasma admittedly looks cool, but I would very much like to see implementations of standard ".desktop" files available on the work area and such.

What would all of this standardisation allow? Well, it would mean that Redhat developers can release a Mugshot program which works with all major browsers, since they would all use the same plugin architecture. Of course this would just reimplement a current feature (albeit in a better way), but if every level of the system was available via a known API then Mugshot's features would be truly limitless. No longer would Music Radar need to understand different media players, because every media player would send the same messages (probably through Dbus) about current song, play/pause, etc. Instant messaging could be properly integrated throughout the desktop. Collaboration on documents and other files could happen much more easily, since different word processors would all understand the same editing API.

Now, many people out there will find this very familiar. There is a good reason for this. It is called the UNIX philosophy!

PS: It's 1:14AM and I'm tired. I'll add link and clean it up later :)