Correcting for Blurred Vision: Local vs Online Posts
Early on, I trashed my local version of Radio by fooling around with the databases within my www folder. Don't worry about what this means for now (it isn't something you stumble into by accident) but concentrate on the result and the design principle revealed.
What was the result?
I ended up with posts on my public weblog (the one located at the Community Server) that were no longer accessible on my local version because the Radio reinstallation had copied over the database on my desktop that contained the original posts.
In other words, I could see them at the public URL of my weblog but not at http://127.0.0.1:5335/ (my actual local version of Radio).
This can cause not only confusion but frustration. Trust me. Yet, this does not reveal a weakness in the Radio design. Radio functions here exactly as it was designed. Reading this topic will give you insight into that design.
Along the way to understanding, take this advice to heart:
Backup your important Radio files before you experiment with new Radio features.
One Version of Radio, Copied Elsewhere
Still, how come I can't 'get to' the posts at the Community Server (or any other site to which I have broadcast them) and 'bring them back into' my local desktop version of Radio?
Or, to put the question differently, how come I can't synchronize between the two 'versions' in a round-robin fashion?
The answer is simple: when you publish a weblog from your desktop to another source online, the two weblogs do not share a computational connection. In simpler English, when you publish, it's 'bye bye' to control over your distributed content.
(You don't really have two versions of Radio anyway. You have one version on your desktop. The stuff you publish is just a copy of that).
Now, could Radio be designed for round-robin synchronization? Sure.
Your brain could be redesigned so the IRS tax code made sense too - that would just entail a 'small matter of (re)programming'. And anti-depressants.
Actually, redesigning Radio would be far easier than redesigning yourself as described above. The good guys at Userland may get around to synchronization someday. But why don't we give them a chance to nail down the boatload of features they have already given us first?
The Broadcast Process
Think about the weblog broadcasting process this way:
You create, edit and post all material in-and-to your desktop version of Radio.
When you publish your posts (that is, when Radio upstreams them), you have sent a copy of your posts to a site that is walled-off from your local version. Publishing is one-way. You have no more direct access to retrieve content from that site than any other Web trawler.
(The key word here is 'direct'. You can copy-paste content from your public weblog just as you can from any website. That would be a very time-consuming but do-able method for recovering lost content if it happens to you).
If, unlike me, you didn't brainlessly trash your local database, you can - of course! - edit or delete older posts in your Radio desktop browser. When you then publish the deleted post, it disappears from the Community Server. But this is still a one-way broadcast operation, not two-way synchronization.
The bottom line is this: if you lose data in your local version but the posts are still visible publicly, you are out of luck if you want to change those dangling posts.