April 30, 2002
Considerable discussion related to my assertion that Radio and Blogger are centralized web publication systems.
First, a caveat -- the use of decentralization that I made yesterday had to do with web publication without dependence on a centralized tool-specific server that you can't, personally, control. It had nothing to do with the P2P concept of decentralization, and it had nothing to do with the fact that you can host your individual pages on your own server. It was specifically related to the web publication tool, itself.
Based on this, further clarification on my statements from yesterday:
Any publication system that requires that one aspect of it be centrally located -- such as Blogger -- is a centralized publication system. Yes, you can host your published pages on your server, but you still have to use the centralized Blogger system to publish these pages. This makes Blogger a centralized rather than a de-centralized solution.
From my understanding, Radio also requires access to what Userland refers to as a "cloud" to manage part of the publication process. And my understanding is that all or part of this cloud exists on the Userland servers. It is very simple to post pages to an individual server using Radio; I've done this myself. However, you're still dependent on a Radio cloud.
Am I incorrect in this understanding? In other words, if I host my Radio pages on my own server and Userland's servers all go down, will any part of my publication process be impacted? I'm not talking about weblogs.com -- that's not the point. The point is, is a centralized Radio cloud necessary at some point for the publication process?
I have to think it is when I read something such as this:
Radio UserLand implements a powerful feature called upstreaming which mirrors the contents of the user's www folder in a folder on www.ourfavoritesongs.com, which is a 24-by-7 public Web server at a fixed location. When a file is changed it's automatically copied to the server through XML-RPC. This makes it easy to publish static content to the Web even if you don't have a full-time net connection, or if you move around. The url of each user's folder is included as an attribute in the users.xml file.
When Radio UserLand launches and as it's quitting it sends a hello or goodbye message to OurFavoriteSongs.Com. This sets the user's signed-on flag true or false and records the users TCP/IP address and port, so that it knows how to communicate with Radio UserLand. (The chat facility is an example of the use of the IP address and port.)
However, perhaps all these centralized aspects of Radio -- aggregation, upstreaming, logging on, etc -- can be turned off to the point where you can totally decentralize your publication process from Userland. If this is so, then I apologize to Userland for making the statement about Radio having centralized tool dependencies.
Posted by Bb at April 30, 2002 10:40 AM
It doesn't make any difference if Radio is decentralized or not, as long as you're using their centralized server. For those users, it IS totally centralized. And for the 3rd day in a row, radio.userland.com is totally offline.
The situation at Userland is totally out of control. They are censoring messages on their support boards that are even mildly critical of their handling of this incident. At the same time, Dave is posting links on scripting.com to the "Chilling Effects" website, where people are invited to post their stories of internet censorship. I think I have a story for them.
You wrote: "In other words, if I host my Radio pages on my own server and Userland's servers all go down, will any part of my publication process be impacted?"
Radio renders pages on its own. It can then upload files via FTP. Whether UserLand servers are up or down makes absolutely no difference in this case.
Another point -- you can also look through Radio's code to see what's going on. It isn't open source, but you can still see the scripts that power Radio.
Brent is right on the ftp publication, my site is hosted elsewhere, and nothing in the pub process ties it to Userland.
No Shelley. I ftp to my own serverspace with Radio and it isn't affected at all.
So, Brent and Michael, I can spend a day using Radio to publish to my server and turn off switches so that my Radio installation doesn't connect to the Userland servers -- at all unless I specifically ask it to. Based on my choosing the appropriate options.
No notification to a stats application when pages are accessed. No ping to userland when I connect with Radio in the morning. None of this -- if I so choose, correct?
"None of this -- if I so choose, correct?"
Brent -- Including the ping and answer that occurs everytime I shut down and start Radio? This doesn't go to Userland?
If not, then I do owe Userland an apology -- the tool isn't connecting up with Userland's servers at any time during the day (as long as you choose to FTP to your server and make sure to not include the referrer script from the template, and don't enable aggregation and upstreaming or chat).
"Including the ping and answer that occurs everytime I shut down and start Radio? This doesn't go to Userland?"
There's a way to turn this off. (And there's a way to have it go to some other server.) Even if there weren't, that ping would be irrelevant to your ability to publish pages to an FTP server of your choice.
Also: about the referer script, aggregation, upstreaming, and chat -- you can go through a server other than UserLand's. Other people can run a Radio Community Server (it's free and there's a Python version, for instance).
For aggregation you don't need a centralized server at all. The way it's configured out-of-the-box you share your subscription info w/ UserLand, but you don't have to.
How do you shut of the ping to Userland on startup and shutdown?
In other words, how do you configure Radio to be *completely* independent of Userland or anyone else (assuming that you are ftp'ing to your own space.)
Moving your content to another decentralized server in times of outage is not a solution to the current Radio problems. You can move your content, but can you move the hundreds of links everyone made to your old site? The solution is decentralization WITHIN the Userland server. The most basic step is setting up a backup server. Until yesterday, there was no backup server at Radio Userland. It's still not up and running yet.
The idea - as shared by Shelly - and I believe in as well - is not to do so at times of outage - but to do so as standard practice.
Blogger has been cursed with this issue for a long time and is hit in both layers the tool is centralized and the host is as well. Double trouble.
At least with Radio, if the server was wiped - you'd still have your content safe on your desktop - ready to redeploy someplace else. That's not a bad feature if you ask me.
Of course with Radio - the opposite is really to be scared of... if your personal machine goes you're in deep shit.
I don't know how much experience you have with web apps censored (nice name). But shit happens. Servers go down. It's the name of the web game.
If you don't want to invest in getting a host at an ISP... why not Geocities with Radio? It's doable. Then you have Yahoo! supporting your're web host.
Take some initiative dude. There are those in the Radio community that will help you move if you ask.
Radio wants to ping somebody. To cut the cord to Userland completely, you can set up your very own Radio Community Server. It's free, and can run on the same desktop machine you run radio on. Once you get it set up, just point your Radio application to your new RCS at http://127.0.0.1:5335/system/pages/changeCommunityServer , and you're done (you also may want to turn off the "notify weblogs.com" preference at http://127.0.0.1:5335/system/pages/prefs?page=2.8 ).
You're still "centralized" if you want to be really anal about it in that you still depend on Userland for updates, aggregation, etc, but the basic weblogging functions are completely independent from Userland and you can operate completely "under their radar" and not have any communication with them whatsoever if you choose.
If people want to run Radio, go for it. I could care less. But unlike what Mr. Robb says, it isn't "fully decentralized" if there's a dependency on the RCS, even a small one. Now, you can host your own RCS, but this is going to be a hell of a lot more overhead than anything Graymatter or MT will generate.
Now, if Dave or Brent or Lawrence wanted to drop a comment or an email to discuss this, I would have clarified my statement and pointed out that the centralization needs are very small, and that this centralization isn't necessarily Userland dependent. Cool.
However, when Dave says something like "Burning Bird, the source of the incorrect information", I am going to respond. And a clue for you guys, I sure as hell know my fucking technology.
Here's a note to Userland and Radio groupies -- if you come at me with the guns, I'm going to verbally cut you off at the knees and at the neck and use your torso as a net during a game of mental soccer.
If there's any dependency at all on a centralized "cloud" -- no matter how small -- then the tool is not "fully decentralized".
Again -- Brent said that this handshake with the RCS can be turned off, making the desktop Radio totally independent of an RCS. If this is so, I have said I would apologize. And I will.
Otherwise -- I stand by what I said.
Have a nice day.
I'm not actually at all interested in turning the handshake off, why bother? And in any case I only half trust Radio for the reason that Karl pointed out: if the machine it is running on dies - deep shit indeed. (and no, I'm not going to back up Mb's of files everytime I post.)
I *am* curious as to how that ping could be disabled though - and I'm curious as to what it actually is there for.
I still stand by what I said though - Radio is a fascinating bit of software. :-)
By the way - please don't cut me off at the knees, as my girlfriend thinks it's sweet the way I sometimes curl my toes. :-D
By the way - thanks Paul Victor, interesting stuff. My own community server eh? That'll impress the girls. :-)
That pretty much is one of my issues Rogi. I don't want to 'admin' my home machine too much :) I like having an ISP I can yell at :) That's another one of the reasons I don't host a site from my cable modem. I really don't want that responsibility. Just run ZoneAlarm to get an idea of how bad it is out there. Ugllllyyy. Now within an administered work intranet... that's different of course.
Shelly, If I disable Radio's use of an http proxy (therefore effectively disabling any of it's xml-rpc messages, from what I understand), I'm still able to publish to my server via ftp (this firewall allows me outbound ftp without a proxy). In my mind, at least, that shows a lack of dependency. I'll admit there is likely some amount of functionality I loose this way, I'm still able to use it for weblog publishing. It's a matter of perspective, I guess.
Rogi wrote: "I *am* curious as to how that ping could be disabled though - and I'm curious as to what it actually is there for."
I didn't see an obvious way -- short of commenting out the code. If there isn't an easy way to turn off the ping, then I'd say it's a bug. But I don't work for UserLand anymore so I can't make that call. (Nor am I a Radio groupie.)
The ping is there to let the community server know you're online and what your IP address is, so you can use things like chat.
If the ping fails for any reason, you can still publish to an FTP server of your choice. The ping is completely irrelevant to the rendering and publishing process.
So, bottom line: the ping is not a centralized dependency for the publishing process.
Brent, thanks for responding. I would say that Userland needs to adjust the product so that there is no connectivity to an RCS if a person so chooses. However, as you said, not your call since you don't work at the company at this time.
I appreciate you taking your time to respond.
There appears to be one more potential problem with the link between Radio and UserLand. Today I get an error posting to my copy of Radio with the MetaWeblog API using my own client. That is presumeably because last night Radio updated its parts and got something that broke MetaWeblog. So maybe automagically updating your software isn't always such a cool thing.
I'm getting out of my depth here - but firstly, Karl: ZoneAlarm is not safe, it's easy to spoof past it as a 'trusted app'. And Brent: Thanks for the reply.
I must say that there seems to be either paranoia about Radio, or a hidden agenda here. It's a very cool app, as is MT, and I'm not quite sure why this conversation is happening, so I'm going to leave it and look at the amazing pic that Shelley has posted further up.
I wrote "Karl: ZoneAlarm is not safe, it's easy to spoof past it as a 'trusted app'"
Apparently, I forgot to write, 'apparently' there. (Legal guys here are freaking at that little 'mistake'. Hehehe :-)
I don't think Radio Userland is a centralized weblogging tool. Though it has the ability to make use of centralized features, none of them are required to publish a weblog via FTP. If the centralized servers go offline, you can continue publishing via FTP without interruption.
The main thing RCS or a clone offers is the ability to store and delete files via XML-RPC instead of FTP. PyCS also offers built-in support for comments so you don't have to use a Manila weblog to store messages.
The overhead for PyCS is probably higher than GreyMatter (if GM just requires some Perl scripts, as I understand it). PyCS requires Python and a database called MetaKit.
The developer of PyCS is working on a new clone that doesn't require anything other than PHP on the server: The PhpStorageSystem:
When it's done, I think it would be accurate to say that non-FTP Radio hosting is easier than GreyMatter.