Drone is a Java IRC bot written with the RIFE framework. It has a modular API that makes it possible to easily extend and customize the active feature set.

It sports a modern web administration interface to handle all common tasks and a public logging section with an advanced web search. It also provides a remote IRC messaging REST API to allow easy integration with notification services. Installation is done by simply dropping a war in your servlet container or by running it straight from the standalone distribution.

The highlights of this release are:

• cleaner URLs in the public logging section
• bugfixes related to correct handling of unknown encoding characters

Visit the homepage at for more details:
http://drone.codehaus.org

You can see it running at:
http://servlet.uwyn.com/drone

Download it from:
http://drone.codehaus.org/Installation

Have fun!

After having spent 3 months working hard to get the new Fumble web site running perfectly with RIFE, I decided to change my approach for the sibling Grumble site that is somewhat similar in functionality.

Instead of just using the raw RIFE approach, I started with what I now call RIFE/Fumble and woooow ... it was up and running in a matter of seconds. In a single line I already had a functional site. The only thing that was left to change was the design, some configuration settings and a couple of additional code snippets here and there. RIFE/Fumble has really changed my life and I can't image ever having to code another site without it.

It's addictive, every line I write just works exactly as I want, and instantly! I spent 60 days writing this with raw RIFE before, and I did it now in 2 days with RIFE/Fumble, that's a 30x improvement in productivity!!! I still have the last 20% of Grumble to write but since everything went so fast, I'm sure it will be done in the next couple of hours!

Mark my words, RIFE/Fumble will revolutionize the world of web application development. Don't even think of trying it out without being prepared to suffer from severe withdrawal symptoms when you have to go back to raw RIFE afterwards!!!

(disclaimer: this story is purely fictitious and any resemblance to real projects or testimonials is purely coincidental)

After the initial launch of Bla-bla List, I received many interesting comments and remarks (and a whole shitload of pointless messages too, but I'll just let those be for what they are). One of the features that some people seemed to be criticizing, was that the small and compact Laszlo interface always stayed fixed and never could be resized. Supposedly, Laszlo was to blame for this, which is not true.

I developed most of Bla-bla List's current UI with Laszlo 2.2.1 and ported it over to 3.0b2 in two days, just before announcing it. I did this since I wanted Bla-bla to be able to support international characters through unicode. However, in the haste I overlooked a feature of the previous 3.0 beta release (v3.0b1), which allows your canvas to be specified as percentages and be dynamically resized.

This morning, I thus spent an hour changing all dimensions to correctly adapt to a resizing canvas. The result is a fully resizable Flash application written in Laszlo. Even though I'm still not fully sold on a Flash UI, this brings it one step closer to being a worthy contender to plain HTML interfaces.

I'm posting this as a reply to David's post.

David, I intentionally didn't go into a language or framework comparison in my original post. I deliberately kept it very factual. Your comparison simply doesn't hold up. You can't just take a worst-case code snippet, compare it with your best-case snippet and make general statements about the whole technology. If your ratio would apply generally, I would have ended up with 4200 lines of code ... but I didn't, I ended up with 900.

As on my blog post, I will not make this a low-level code pissing contest. You said yourself that Ta-da List took 600 lines of code, they're probably just situated elsewhere. You did write those hundreds of lines of code.

David, I'm by no means saying that our technology is better or that yours sucks (however you seem to have a habit of doing so). We just can't make a decent comparison since you don't have the slightest clue about RIFE, just as I haven't got got the slightest clue about Rails, we both at best just skimmed the surface.

You can now however stop making your useless out-of-context lines of code statements, since they simply don't hold up anymore and make you look silly.

Almost two months ago, I wrote a blog post about Ta-da List. I wondered why it even took 600 lines to write if Ruby on Rails was as revolutionary as the authors claimed. Some people said that I had to back up my statements by implementing it myself in another technology, and that's what I did. The result can be seen at http://blablalist.com.

The implementation has been done in RIFE, Laszlo and Java. If you're interested, you can peruse the sources by going to the Subversion repository. I will be releasing packaged binary versions soon.

The application has 752 lines of Java code (empty lines, comments and imports removed) and 155 lines of XML code. This is only 300 lines more, while Java and XML are a lot more verbose than the Ruby language. It's certainly a lot less than the triple size that some people predicted. Now, let's leave the LoC wanking behind us.

Bla-bla List does a number of things differently and has some additional features:

• continue what you were doing when your session times out

  update: Ta-da has been fixed to check the user's session for these operations. Of course when your sessions now times-out, your data is just lost. You don't get any warning message (which I hope they will at least fix in a later version).

  Tada has solved this by removing the feature.

  Ta-da list tricks you into thinking that this behavior is done securely. Most edit operations are actually performed without authentication. For instance, look at this URL http://tadalist.com/lists/public/1605. If you look at the HTML source code, you'll see the IDs of the entries.

  Now, toggle the status on one of them (you can replace the 0 by a 1 at the end):

  http://tadalist.com/item/toggle/28161?completed=0

  However, maybe you think that some things are missing, so why don't you add an entry:

  http://tadalist.com/item/add?list_id=1605&content=Places+to+visit

  You can mess up any Ta-da list like that! Just pick one out of the collection that you see here. I could make very nasty comments about this, but I'll keep this post civilized.

  Bla-bla List ensures that all this is done securely and that you never lose data when your session times out. This is done thanks to an unique feature of RIFE that we call behavioural inheritance.

• secure private sharing

  When sharing a list 'privately', Ta-da sends the invitees a non-protected URL. While they list this behavior as one of the features, I think that private lists should be secure at all times. I thus implemented a ticket system that adds shared lists to the invitees account through unique invitation URLs that can only be used once.

• customizable short names for public sharing

  Ta-da generates non-intuitive public URLs that are beyond the user's control.

• fully functional REST API

  As far as I know, Ta-da uses XmlHttpRequest and returns snippets of HTML and JavaScript. I think that an independent REST API has a lot of potential and implemented that instead.

• lists can be reordered

  Ta-da simply doesn't allow you to do this.

• drag & drop to reorder entries and lists

  Ta-da requires you to click awkward arrow buttons.

• automatic installation at first startup

  Ta-da is not packaged nor distributed, but I doubt that the installation is part of its line count or even included in the source.

• the UI is designed to be small

  Ta-da uses large fonts and takes up the whole browser window. I think it's important that the window can remain open without cluttering the desktop.

• only public RSS feeds

  Ta-da has RSS feeds for all lists (private and public). Currently I only implemented the public version since I want to make the private one secure and I'm still doubting about what would be an acceptable way for users to do this.

• open-source

  Ta-da never showed their code nor released it under an open-source license.

Since I think that a number of people might prefer my implementation, I decided to host Bla-bla List myself in a similar fashion as Ta-da.

I'm quite interested in rich internet technologies and I'm planning on building a number of other client-side tools that communicate directly with the REST back-end. For instance: an Ajax and a Xul version of the current GUI, a MacOSX Tiger Dashboard widget, IDE plugins (IDEA, Eclipse, Netbeans), a Gnome applet, a mobile phone version, ...

This will make the application much more useful and provide an open-source comparison base for these technologies.

Have fun with Bla-bla!