We found the DropPlay interface painless and fun to use. The YouTube integration was pretty seamless and there is a quick setting to compensate for a slow network connection. Plus, there is a lot of potential for the social side to really explode with the decision to go with Facebook Connect. It's still a little rough, but for an initial beta release, overall, we don't have a lot of nits to pick with the way it works.

However, we do have some thoughts we'd like to address overall.

First, just like with Muziic, this service leverages YouTube specifically for music videos (via the YouTube API) and appears to not honor YouTube's advertising model. This means that it is, in essence, getting the 'milk for free,' something that we believe can last only so long until Google clamps down on this sort of behavior, either by making the API more restrictive or being more aggressive about removing music videos.

Second, although Facebook Connect is used so that you can easily log in, find Facebook friends, and save playlists, there is no export option once your playlists are created. This means that all the work you do lives in this app, and you must resign yourself to a possible future where the site may disappear one day and any playlists or shares will vanish with it.

Finally, there seems to be no support for sharing any discoveries you make in DropPlay with outside services, except perhaps your Facebook friend's wall. There's no link back to the original YouTube video and no sharing options via email or other social network. While this approach seems to mimic Facebook's own original 'walled garden' approach, even Facebook realizes they themselves must become more open and share more social graph data with other networks.

A hot topic in the blogging world recently has been: is Microsoft's Internet Explorer browser dead? Ironically, most of the good stuff to read has been via "Comments" forms - ie readers writing back to a weblog post. Robert Scoble from Microsoft said "The right question is: 'is the Web dead in Longhorn?' " and he got over 30 comments written to his weblog. Some were the usual bleatings about fixing CSS and why can't IE have tabs like Mozilla, etc. I posted a comment myself, which said: "How about converting IE into a browser/editor, so we can read and write the web at the same time??" I put no justification into this remark, as I was just curious to see if I got any bites. Well Robert himself replied, saying yes he'd like that too. But he also said something about not wanting to upset weblog vendors. This response was deleted from the Comments section soon after, as I can't find any trace of it now. But never mind about that, I liked hearing that the concept of a browser/editor is being kicked around in the Microsoft world.

Weblog tools have come close to achieving the 2-way web dream of allowing people to both browse and edit the Web. But I don't believe there is an existing tool that bundles (dangerous word) the browsing-writing-aggregating functionalities into 1 product. I use Radio Userland as my web writing tool, Feedreader as my RSS aggregator, and (you guessed it) IE as my browser. It would make sense to have an all-in-one tool that does all 3 of those things, not to mention also being a PIM (Personal Information Manager) a la Chandler or Haystack. 

A few bloggers believe Microsoft's plans go even further - that the browser will be integrated (a nicer way of saying bundled?) into Microsoft's next-generation Longhorn OS. Or as DonXML nicely put it: "Longhorn has become the first major step towards a Web Based OS". If you throw writing and pub-sub functionality into this new web-based OS, then weblog vendors would have reason to be afraid. Or do they? Maybe it will come down to who innovates the best, who has the most functionality you require, whose dream you buy into (think Open Source ideology). 

The web browser as a product may well be as good as shelved by Microsoft. But as Tim Bray points out: "...what program, I ask, do most users spend most of their time in? The web browser." Ergo, if Microsoft's most used product is being obsoleted, you can bet there will be a replacement that does what the browser did and much more.

After a few late nights, I've successfully implemented Easy News Topics (ENT) tags to my Radio Userland RSS feed. It wasn't as easy as I thought it would be. It involved rooting around in the Radio.root file of my weblog and upskilling myself in UserTalk, Radio Userland's scripting language. But mostly I stood on the shoulders of giants to get this done - Dave Winer and Matt Mower in particular.

ENT is an extension of the RSS2.0 spec. Its aim is to enable categorization of RSS items into topics. After reading about ENT and writing one of my first articles about RSS topics, I decided I wanted to actually implement ENT into my weblog. After some initial searching, I came across an article by Dave Winer called "How to extend Radio's RSS generator". This introduced me to 3 new "callbacks" which enable Radio developers to modify their RSS feeds. The callbacks are: writeRssNamespace, writeRssChannelElement, writeRssItemElement. The first one I successfully implemented was the namespace. I did this as follows:

1. Open up your Radio.root file.
2. Drill down to user.radio.callbacks.
3. Double-click on writeRssNamespace, then re-name "item #1" to "ent".
4. Enter the script linked here.
5. Click "Compile".

That was relatively easy. Implementing the item elements turned out to be trickier - particularly as the elements have attributes and are nested. It took me a while to get to grips with the UserTalk syntax, not being a programmer by trade. I bumbled around a bit and got to a stage where I juuuust about had the script right. Then I happened upon Matt Mower's conversation with Dave Winer and finally things fell into place. Here now is my code for the writeRssItemElement script - same process as above.

But wait, there's more. Because the ENT tags are nested, there is one more piece of scripting you need to do -  modify writeRssFile. But luckily Matt Mower, one of the authors of ENT, has already done the work - right-click here to download the script. Open this in your Radio app, and it will automatically save itself in the workspace area of Radio.root. Then you need to copy it across to the following location:
system.verbs.builtins.radio.weblog.writeRssfile

btw as a sidenote, writeRssfile is just one of many very clever scripts built-in to Radio. It's amazing how much data there is in Radio.root, once you have a good poke around. It's a testament to the amount of work Dave Winer must have put in to build Radio Userland, so I do sympathise with his recent posts about software developers gettin' paid.

Anyway that's basically it for stage 1 of implementing ENT into my Radio RSS feed. Stage 2 is to actually put some worthwhile data into my topic tags - currently I've just got dummy data in there. Ideally I want to dynamically generate a topic word or phrase for each weblog post, based on the contents of the post and/or the title. But I guess this is where k-collector comes in. So that's my next project, to find out about k-collector and put some meaningful data into my shiny new ENT tags :-)