Core feed publishing
Chris- There are a number of people already working in the direction you propose, and we'd love to have you join in. Core aggregator is totally separate from the node system, so I don't understand where you are coming from. I'd encourage you to join http://groups.drupal.org/rss-aggregation if you are not already a member. We are trying to coordinate efforts in this corner of Drupal. We especially need reviewers for Aron Novak's Summer of Code work. http://groups.drupal.org/node/4624 and related. Aron's work is targeted as contrib for Drupal 5 & 6, with application for core in Drupal 7. In particular, take a look at the proposed API, which has been in the works since the last DrupalCon. http://groups.drupal.org/node/3528 and is foundational to Aron's work. - Ken Rickard agentrickard Message: 10 Date: Mon, 2 Jul 2007 23:02:14 -0400 From: beerfan <beerfan@gmail.com> Subject: [development] Core feed publishing To: drupal-devel@drupal.org Message-ID: <8de7f7140707022002ya99539fg711d32e052f63cb5@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Feed publishing, and the RSS format in particular, is currently tightly coupled with the node module. Because of this supporting Atom or extending feed functionality with custom modules isn't as clean as it should be. For example, adding a name-space to a node feed requires replacing default feeds with custom feeds instead of simply "theming" the output of feeds as you would do with every other form of content display. Publishing only Atom feeds (and disabling RSS) is impossible. I would like to see feed publishing become more generic and more extensible in the core and I believe there has been discussion around this in the past. Ideally, feed publishing would be a generic module or api which would support the following needs. 1. Multiple arbitrary feed formats (RSS, Atom) with a default 2. Custom name-spaces and elements (possibly via themes or hooks) 3. Publish comment feeds or any other arbitrary content (watchdog events, users, etc.) 4. The ability to provide a feed of any arbitrary set of content (e.g., view, node-queue) 5. Optimize publishing for very high traffic feeds (e.g., caching or saving as static xml file) 6. The ability to disable feeds It is currently possibly to cobble together most of the above functionality with views.module, commentrss.module, and atom.module but the solution is sub-optimal for many reasons. I recently started creating a feed.module against HEAD with the hope that it could turn into a core module which would make feed publishing more flexible and collect all feed formatting and publishing code and eliminate the RSS publishing functionality in node.module. However, since 6.x was just frozen there's probably no hope of introducing this now but I'd still like to re-float the idea and get some feedback. In particular, I'm curious if anyone else is already working on such a project, if there are any side-effects of separating feed publishing from node.module that I haven't considered, or if this problem might be better approached using views as the complete solution (not really viable since views is not a core module). Please ignore the fact that this can't be implemented for 6.x. As an example of an issue I have faced, feedburner.com adds a "number of comments for this entry" if the feed includes the "wfw:commentsRss" element pointing to the comment feed for the entry. I have modified the commentrss.module to add the element to the node feed but there is no way to add the "wfw" name-space to the node feed without replacing it with a custom feed so I had to add the name-space to each instance of the "commentRss" element. Cheers, Chris Cook
Ken: It would be useful if you responded to threads directly. On 7/4/07, Ken Rickard <agentrickard@gmail.com> wrote: There are a number of people already working in the direction you propose,
and we'd love to have you join in.
Core aggregator is totally separate from the node system, so I don't understand where you are coming from.
Because he was talking about publishing/syndication, not aggregation. i.e. today we have RSS2 output hardcoded. Having a more flexible layer would allow for different formats for syndication -- from Atom to JSON to arbitrary XML data formats. This is likely going to be tackled most easiest with a Drupal7 + Views + PHP5 XML support combo. -- Boris Mann Office 604-682-2889 Skype borismann http://www.bryght.com
Boris, This is one of the things that the combined 'node building/node rendering/output formats' refactoring is intended to tackle. Hopefully, once the D6 cycle has his RC or so, and a number of folks can brainstorm in Barcelona and g.d.o., we can hammer out a clear path forward that solves a number of these interlocking, overlapping problems :) --Jeff On Jul 4, 2007, at 1:49 PM, Boris Mann wrote:
Because he was talking about publishing/syndication, not aggregation.
i.e. today we have RSS2 output hardcoded. Having a more flexible layer would allow for different formats for syndication -- from Atom to JSON to arbitrary XML data formats.
This is likely going to be tackled most easiest with a Drupal7 + Views + PHP5 XML support combo.
Wednesday, July 4, 2007, 2:49:24 PM, you wrote:
Core aggregator is totally separate from the node system, so I don't understand where you are coming from.
Because he was talking about publishing/syndication, not aggregation.
Syndication is the clear term here. "Feed" causes the confusion... Alex
i.e. today we have RSS2 output hardcoded. Having a more flexible layer would allow for different formats for syndication -- from Atom to JSON to arbitrary XML data formats.
This is likely going to be tackled most easiest with a Drupal7 + Views + PHP5 XML support combo.
-- Alexander Barth Development Seed http://www.developmentseed.org http://www.developmentseed.org/blog lx_barth(skype) alex_b(drupal.org) Tel. 202.250.3633 Fax. 806.214.6218
participants (4)
-
Alexander Barth -
Boris Mann -
Jeff Eaton -
Ken Rickard