cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthew Langham" <mlang...@s-und-n.de>
Subject What can we learn from Radio [was: [provocative] crushing userland]
Date Mon, 18 Feb 2002 11:37:02 GMT
>>
Anyway, that's a quick overview. Overall, Radio is kind of weird, very
quirky and has more then its share of bugs and annoyances, but I still
find myself liking it more each day I use it. It feels dirty to say that,
but it is what it is.
<<
I have to agree with Kimbo here. The more I use Radio the more I find myself
liking the way it works. The only real problem I have is not being able to
update my "cloud" from home and work easily - but that is really a different
story.

Anyway, I do not see Cocoon as being competition to Radio as the two
concepts are quite different. However there are a couple of points that
warrant looking at to see how Cocoon could be extended to offer similar
functions.

As we have been discussing there is the blogging side (i.e. Cocoon acting as
a blog server). I still think this would be an interesting feature to
provide and would exist well in for example a portal. And implementing
something along the lines of the blogging XML-RPC api which feeds Xindice
should be pretty easy.

Something else that Radio handles extremely well is being able to call web
services from the Radio environment using macros. Now again, being able to
integrate web services as datasources for a portal would be neat. And
imagine if you only had to write something like:

<soapcall>["soap://localhost:5335/"].examples.getCurrentTime ()</soapcall>

to call a SOAP service from inside Cocoon. That's how easy it is from inside
Radio.

So while I don't think anything will be crushing userland soon - I _do_
think there are some interesting ideas there.

Matthew

--
Open Source Group               sunShine - Lighting up e:Business
=================================================================
Matthew Langham, S&N AG, Klingenderstrasse 5, D-33100 Paderborn
Tel:+49-5251-1581-30  mlangham@s-und-n.de - http://www.s-und-n.de
           Weblogging at: http://www.need-a-cake.com
=================================================================

-----Original Message-----
From: Kimbro Staken [mailto:kstaken@xmldatabases.org]
Sent: Monday, February 18, 2002 11:51 AM
To: cocoon-dev@xml.apache.org
Subject: Re: [provocative] crushing userland



On Monday, February 18, 2002, at 02:23 AM, Ugo Cei wrote:
>
> Done.
>
> I gave a quick look at Radio in the weekend and seen that it is based on
> OPML (http://www.opml.org). I don't really like OPML though. Do you think
> that we should use or support OPML, or use some other kind of markup?
>

Radio isn't really based on OPML, it's more based on plaintext. If you
looked at the native app then everything is a really funky outline thing,
that isn't really what Radio is to the user. Look at the web interface and
the files generated through that. The native app just  sits in the
background and controls everything. If you want to modify the code behind
Radio, or access the object database directly, that's when you dig into
the Radio app itself.

Radio uses a combination of the file system and its object database to
store content. Most things go into the file system, but actual weblog post
contents are stored in the object database as text. All typical end user
interaction is through a web browser. When you post a new weblog entry it
generates several static web pages and an RSS file and automatically
uploads them to one or more servers.

The system does a lot of processing of the posted text, like turning
things it thinks are URLs into links, email address into mailto links and
automatically wrapping paragraphs in <p> tags. It has keyword expansion
that can lead to unexpected and annoying results sometimes, especially
since it isn't clearly documented. It also has macro capabilities that you
can type directly into your posts. All of this stuff is used to generate a
static web page, the published site isn't dynamic at all.

The system also monitors a directory hierarchy on disk so that any file
you drop into it will automatically get published to the server. Dropping
a .txt file will result it in it being turned into a web page with all
your styles applied automatically. It applies the same processing there as
it does for weblog posts. You can have different styles for different
parts of the tree and can have them publish to different servers.

Style and publishing controls are done through text files in the file
system. Any file that begins with a # is a Radio system file and won't be
published to the server. Dropping the same file deeper in a hierarchy will
override all like named files higher in the hierarchy.

Anyway, that's a quick overview. Overall, Radio is kind of weird, very
quirky and has more then its share of bugs and annoyances, but I still
find myself liking it more each day I use it. It feels dirty to say that,
but it is what it is.

> 	Ugo
>
> -- Ugo Cei - Consorzio di Bioingegneria e Informatica Medica
> P.le Volontari del Sangue, 2 - 27100 Pavia - Italy
> Phone: +39.0382.525100 - E-mail: u.cei@cbim.it
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
Kimbro Staken
XML Database Software, Consulting and Writing
http://www.xmldatabases.org/


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message