I believe implementing parsers as pluggable include files (like image toolkits in core) has advantages over parsers as modules.
Does this worth discussing. Any ideas?
I believe implementing parsers as pluggable include files (like image toolkits in core) has advantages over parsers as modules.
Does this worth discussing. Any ideas?
Comments
Comment #1
aron novakFor performance reasons, I think this totally makes sense.
But how to cope with losing hooks? Reimplementing hooks seems too high price for me.
Comment #2
mustafau commentedFollowing are the details:
Define hook_aggregator_parsers() to be implemented by modules that provide parsers.
Example for aggregator.module:
Define hook_PARSERNAME_info() to be implemented in parsers include file.
Example in aggregator.atom.inc:
Provide a settings page like "admin/settings/image-toolkit".
Ship aggregator with 3 parsers:
aggregator.rss.inc
aggregator.atom.inc
aggregator.rdf.inc
Comment #3
mustafau commentedI have found an interesting patch in the aggregator issue queue and updated it. Here is the patch; #72915: Move feed parser to includes/feed.inc.
It seems that in the past having a "feed.inc" file in the "includes" folder was being considered.
Comment #4
alex_b commentedI like the idea. It could rid us of the problem of having to install two modules instead of one (syndication parser plus aggregator instead of just aggregator).
aggregator.module could implement the hook, all parsing functionality could live in syndication_parser.inc . other modules who would like to use syndication parser without aggregator can include the .inc file themselves...
i'm not so sure about splitting up syndication parser into rss, atom and rdf, i'd at least keep rss and atom in one body, as they're so similar.
Comment #5
mustafau commented#72915: Move feed parser to includes/feed.inc