0xDECAFBAD

GroupWeblogWithRadioUserLand

Revision r1.6 - 08 Oct 2002 - 17:33 GMT - TWikiGuest

[This idea is under development, comments are welcome on this page.]

Introduction & Musings

The biggest reason why I would not want to maintain the weblog on 0xDECAFBAD with RadioUserLand is because it is designed for only one author and one weblog (albeit with categories). Someday I might like to let more hackers in to play. I suppose one could use the Mail-to-Weblog functionality, opening up posting to multiple authors with a common mailbox everyone can send entries to. But, this approach loses most of the functionality of everyone's separate RadioUserLand installations.

The nice thing about RadioUserLand is that there is no server-side software to install for the user. UserLand has community servers to facilitate whatever essentials need to be centrallized, and will even host the content for awhile. So, a group weblog in RadioUserLand would necessarily need to follow this pattern. It should require nothing more than what Radio has available out of the box, such as upstreaming and the community server.

The idea is to try to push all the active processing onto each contributor's Radio installation, and assume that the webserver everyone shares is braindead. It should be assumed that the only thing the server out there serves pages and accepts uploads via upstreaming (FTP, or other mechanism). It'd be nice if the server had a tiny bit of security, if only to limit who can download and update what. But at best, the server is assumed to be content host and drop point for shared data. All processing is done offline.

Can this work? How dumb can we make the server and still have inter-Radio collaboration?

Scenario One: Public News Aggregator

This seems to be the simplest solution:

  • One Radio user appoints him or herself the group weblog maintainer.
  • Contributors post weblog entries to a special category on their own weblog sites.
  • Contributors make their XML weblogArchives available (at least of the group category)
  • Maintainer's Radio subscribes to contributors' special category RSS
  • Maintainer's Radio pulls down and aggregates contributors' XML content
  • Maintainer renders contributors' content in weblog's theme
  • Maintainer's Radio upstreams the content to the group weblog
  • Could allow non-Radio weblog authors to participate
  • No alterations of entries posted by contributors after aggregation?

This would require a Tool installed on the Maintainer's end to do this subscription, acquisition, aggregation, and rendering of group content. Would any Tools be needed on the Contributors' ends?


One problem with using RSS is the clients won't be able to publish immediately to the group blog. New items from clients will only appear when the maintainer's aggregator runs, presumably hourly, and reads their RSSes. The Radio DG discussion mentioned the Blogger API, and it (or the Weblog API from weblog-devel) would remove the aggregator dependence--but require a client-side Tool.

-- MarkPaschal - 06 Mar 2002

RE: lack of immediacy -- This is true. Just trying to think of a way to enable this group weblog assuming there are no smarts on the server and that no members of the group can connect to each other. Say everyone is behind separate firewalls, and the webserver is static content and FTP-only. No CGIs or other web apps. The only way to communicate in this scenario (as far as I have imagined so far), is to drop files in known locations and pick them up periodically. Thus, the notion of RSS (or some other format) aggregation.

-- LesOrchard - 07 Mar 2002

Scenario Two: Shared weblogData.root

This is much more complicated, yet appeals to me. Am I nuts?

  • Weblog data is contained in a guest database weblogData.root
  • Guest databases can be updated from remote sources
  • Could multiple users 'subscribe' to updates to the same weblogData.root?
  • Could multiple users upstream updated to a shared weblogData.root?
    • Using the upstream mechanism keeps the sharing mechanism simple.
    • Version control of the weblogData.root is not so simple.
    • Concurrency, locking?
  • Contributors' Radio installations each take turns uploading HTML rendered content to manage the website.
    • Assuming everyone uses the same weblog skin
  • Security? Not much at all, in this scenario. How to handle it?
    • Coarse barriers: allow only collaborators access to shared weblogData.root and upstreaming, assume they'll all behave?
    • See: Wiki:WhyWikiWorks
  • Weblog management system would need to be heavily reworked to support this.
  • Would xmlstoragesystem.com be a better model for this? Available, but not braindead simple.
  • Biggest benefit is that no one group member is the maintainer, any group member can modify the weblog
  • A downside is that it would be a lock-in to Radio

-- LesOrchard - 05 Mar 2002

News & Status

Downloads

Documentation

References

People

When I grow up, I want to be a computer scientist
Rotating header picture Rotating header picture


Advanced Search

Related Entries

(Disabled, for now.)

Buttons

View items on my Amazon wishlist

Made on a Macintosh Powered by Movable Type <$MTVersion$> Made for Safari Get Firefox You can do better than Microsoft Internet Explorer

Creative Commons License
This work is licensed under a Creative Commons License.