Plone Radius Package
This would be really useful for my job. A Plone package that allows authentication via Radius/RSA would likely mean lots more Plone work for NASA HQ. Once I got a functional prototype I'm sure I could get some funding for more work. Since Wichert Akkerman's pyrad python module is supposedly pure Python this makes integration really easy. I like easy integration.
One thing I like about this potential project is that it should be a pretty quick effort. Actually, the hard part will probably be finding a server to test against.
FeedFeeder Package
Reinout van Rees invited me in a response to this post to take a crack at FeedFeeder when I brought up this issue. The issue?
Feedfeeder assumes the best out of its sources, and assumes that FeedParser is going to return something nice. What if we could make FeedFeeder either assume the worst of its sources, or give FeedFeeder administrators more flexibility in how to handle feeds?
Alas, the problem with RSS (and even Atom) is that people consider the specification (if they actually look at the specification) as mere loose guidelines. I'm not going to point any fingers at anyone because I like my job, but I will say that the ability of Web Browsers to look at anything remotely like RSS and then display the contents like a feed makes life for us Plone developers a pain in the butt.
Periodically, I got people saying, "Include this as a feed!" until I trained them to realize that most RSS feeds are junk. Which is nevertheless embarrassing when the so-called feed that displays as an RSS feed in Firefox or Safari is completely screwy when it comes the XML. In fact, at my job we've pretty much forked FeedFeeder in order to support customer requests, with each RSS feed item being a custom script. The results work and yet are not very pretty.
So my big idea is this that FeedFeeder would be enhanced in one of two ways:
- Custom Scripts - FeedFeeder administrator can do TTW scripts (portable via Generic Setup) to control how FeedFeeder parses the incoming feed. The scripting would be restricted Python. This way the same feed that can be seen via the browser can now be interpreted by FeedFeeder as well. The problem is the normal sort of issues you get with TTW programming, especially when it comes time to validate the script, or port it around (Even with Generic Setup).
- Custom Plugins - How about a plugin system of some sort? Basically, you would follow a standard API and put your plugins in a particular folder. FeedFeeder would pick up the plugin and run the appropriate plugin (we would have a selector tool) against the appropriate feed. This way we could grow the functionality and robustness of the tool as more RSS and Atom feeds are added, and could also support new protocols as they become popular
BTW, Reinout van Rees has responded to all my posts on the subject of FeedFeeder. He commented on my first post, which was me whining about not reading the code, to the second which was deliberating on making a RSS package that was like FeedFeeder, but could handle problematic RSS better.
So hopefully Reinout is going to read this post too and share an opinion. ;)
Yeah, Reinout reads your weblog :-) Lately someone else wanted some additions to feedfeeder. You want some additions. We already build in one addition mechanism. There's only one sensible conclusion I can make: use some optional zope3 pluggability to be able to plug in a special feed consumer or a special feed handler. Perhaps a query for a named utility? Walking over the available utilities till one returns a result (with a sensible fallback of course)?
ReplyDeleteFeedfeeder was originally developed for ONE customer, but with some customizability in mind. I think a bit more customizability is actually needed.
I'm not in a position to promise some developer capability on this, but I'd like to do some thinkwork on this.
In case I take some time in replying to a blog post, please email me :-) I do miss something from time to time :-)
Reinout