Morning brainstorm about FeedFeeder v2

I've been working on a .plan for FeedFeeder v2, but for some reason things were not really coming together. Something seemed off. In retrospect, what was off was that my proposed solution didn't immediately correct the current problem with the otherwise excellent current version of FeedFeeder. And that problem is that any anomalous feeds force you to write and deploy code (ie - plugins) to correct the anomaly.

Sure, the Van Rees brothers had agreed that a future stage would correct the problem via a TTW function, and we would even consider a handy AJAX powered GUI to make it intuitive. However, the issue with that is that it would occur at a future stage, not at a stage that worked with my current use case - that I get feeds from the customer that they want today to work in nasascience.nasa.gov. Speaking on the finanical side, how could I get NASA to pay for work done on FeedFeeder v2 if it doesn't correct our current issues out of the box?

Well, this morning the answer came to me. The solution to the problem was rather clear and simple. Rather than a sophisticated plug-in system what about a definition system? Currently FeedFeeder provides two content types:

• FeedFolder:
  
  • includes a field listing the feeds consumed by this folder
  • and is a container for holding feed definitions and feed items


• FeedItem:
  
  • individual feed content items provided by the feeds defined in the FeedFolder

My solution proposes adding a third content type called 'FeedDefinition' to handle defining of feeds:

• FeedFolder:
  
  • a container for holding feed definitions and feed items
  
  
• FeedItem:
  
  • individual feed content items provided by the feeds defined in the FeedFolder's FeedDefinitions
  
  
• FeedDefinition:
  
  • Defines the source of a feed and how to handle the feed

A FeedDefinition would likely include the following fields in addition to the defaults:

• Source:
  
  • URI of the feed source
  
  
• FeedTitle:
  
  • default: standard
  • otherwise define location of feed title based on FeedParser output


• FeedDescription:
  
  • default: standard
  • otherwise define location of feed description based on FeedParser output


• ItemTitle:
  
  • default: standard
  • otherwise define location of item title based on FeedParser output


• ItemDescription:
  
  • default: standard
  • otherwise define location of item description based on FeedParser output


• Replacements:
  
  • default: empty
  • lines field that shows what text needs to be replaced with other values.
  • example: 'www.nasa.gov -> nasawww-origin1.hq.nasa.gov'

When handling feeds, when a FeedFolder has its update_feed_item action triggered it would:

1. Iterate through its FeedDefinition children.
2. Based off the rules in each FeedDefinition, fetch and parse each feed.
   
3. The parsed feeds would be then added to the FeedFolder as FeedItems.

A supplementary view for FeedFolder would be provided that would not display the FeedDefinition.

Comments? Thoughts? Anyone think I should move my blog to a place that handles comments better?