Radio Crankypants #9-10
Know thy own self, or atleast your market. At the end of the day, I guess the biggest problem I have with UserLand products, to date, is that I am not their market. It is clear that Radio UserLand is a pretty spiffy and powerful little tool. And in a power to the people sort of way, I would probably recommend it highly in most circumstances. The sticking point, for me, is not necessarily that everything is sent across the network in clear text; the issue is that lots of people don't have a problem with this. But I do and if I were managing geek central in any kind of corporate environment, I simply would not recommend Radio. Never mind the debate about whether or not your employees should be allowed to run off at the mouth versus the need to ensure that everyone stays "on the bus" using a workflow mechanism. The problem is that Radio passes potentially sensitive information in a way that exposes it for all the world to see. Update : To be clear, none of the other tools that Michael mentions are inherently more secure than Radio. It's not a widget problem, so much as a transport problem. Radio does FTP rather than SCP or FTPS for file transfers. HTTP instead of HTTPS for (XML over) HTTP requests. There was an effort, maybe a year and a half ago, to teach Frontier to speak SSL but I don't know what ever came of it. What something like Movable Type has over Radio is that it runs behind Apache which is commonly built with mod_ssl. Secondly, the interface for Net::FTP and Net::SCP are exactly the same which means that all a (MT/Perl) developer needs to do is try to load the latter and if that fails, and the configs don't explicitly say to bail, load the former. It would likely be possible to set Apache up as a proxy for Manila to ensure that everything comes in and out of localhost on port 443. This is done in the Zope-world all the time. But in order to really do this hack properly, you also have to add kernel hacks/configs to make sure that traffic to the port that Radio is actually sitting on is only allowed from inside your network and on port 443. Which makes it "do-able" under OS X, nightmarishly complicated under Windows and probably impossible in Classic, where there isn't even a port for Apache. As far as the file transfers go, if someone wrote glue for the various SCP applications (Putty on Windows, NiftyTelnet on Classic and scp on OSX ) then it looks like Radio is actually rigged so that you could write auser.html.callbacks.fileWriters callback without too much trouble. It is unclear to me whether or not there is also a callback framework for "fileReaders". I haven't read the docs yet and there is no fileWriters.ftp.read table in my ODB. 10) Apparently, you can not blog to the past