[drupal-devel] parse_rdf.inc proposal
Hi there, While updating naggregator.module, I decided to put all RDF parsing stuff in one parse_rdf.inc. Naggregator needs it, aggrgator.module, aggregator2.module and most probably more modules could use a general rss parser. I would like to know if anyone wants to help me develop this. And I also would like to hear any suggestions. Questions I have been asking myself are: Should this maybe be a general XML parser.inc, rahter then only a rdf/rss parser? Should I include some general remote-file functions (I already have a general drupal_remote_file()) For now, what i have is loosely formatted after the mysql/database functions in PHP: rdf_get_object($res) rdf_get_array($res) where $res is a result (feed) returned by drupal_remote_file(); Both 'get' functions return one item a time, as object. similar to the 'row a time' the database functions to. On top of that, Id like to see a rdf_get_feed($res) which returns an object with an array ($object->items) containing all the items as objects. Please let me know if you are interested in lending me a hand, or if you have other ideas about getting this in core. Or anything else. Bèr
While updating naggregator.module, I decided to put all RDF parsing stuff in one parse_rdf.inc. Naggregator needs it, aggrgator.module, aggregator2.module and most probably more modules could use a general rss parser.
Don't call it parse_rdf.inc. Only two versions of RSS are actually RDF (RSS v0.90 and RSS 1.0) - all other versions are NOT RDF. parse_rss.inc is a far stronger name, but honestly, I'd name it something like syndication.inc or something (so as to include Atom support). -- Morbus Iff ( you, me, eropuri? aawwwwwWWWw yYeahahhHHAhhh ) Technical: http://www.oreillynet.com/pub/au/779 Culture: http://www.disobey.com/ and http://www.gamegrene.com/ icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
On 23-Sep-05, at 7:14 AM, Morbus Iff wrote:
While updating naggregator.module, I decided to put all RDF parsing stuff in one parse_rdf.inc. Naggregator needs it, aggrgator.module, aggregator2.module and most probably more modules could use a general rss parser.
Don't call it parse_rdf.inc. Only two versions of RSS are actually RDF (RSS v0.90 and RSS 1.0) - all other versions are NOT RDF. parse_rss.inc is a far stronger name, but honestly, I'd name it something like syndication.inc or something (so as to include Atom support).
Agreed - this should be general parse_feed.inc (or somesuch) ... and I would absolutely be +1 for that... In fact, I would like to see a general xml.inc for generalized XML parsing / generation - which then parse_feed could use to handle specifics of feed types. PEAR currently has a package in the proposal stage that does just this: http://pear.php.net/pepr/pepr-proposal-show.php?id=295 Might serve as some inspiration... -- James Walker :: http://walkah.net/
On Friday 23 September 2005 14:06, James Walker wrote:
Agreed - this should be general parse_feed.inc (or somesuch) ... and I would absolutely be +1 for that... I like that name. parse_feed. I dislike the word syndication, for it is VERY unclear what side that serves, the serving or receiving side. and yea, the idea is indeed to introduce a stepstone for proper core XML parsing. but XML is WAY over my head, as is rss parsing in fact already. Though I would love an XML parser API that can be called just like the database systems. The currect default PHP API is very very abstract.
Ber
On 23-Sep-05, at 10:00 AM, Bèr Kessels wrote:
On Friday 23 September 2005 14:06, James Walker wrote:
Agreed - this should be general parse_feed.inc (or somesuch) ... and I would absolutely be +1 for that...
I like that name. parse_feed. I dislike the word syndication, for it is VERY unclear what side that serves, the serving or receiving side. and yea, the idea is indeed to introduce a stepstone for proper core XML parsing. but XML is WAY over my head, as is rss parsing in fact already. Though I would love an XML parser API that can be called just like the database systems. The currect default PHP API is very very abstract.
well, what I'd like to see is a drupal-like wrapper around php's raw xml stuff... actually, i think the best thing - for our uses at least - might be a drupal wrapper that mimicked http://ca.php.net/simplexml - and was even smart enough to actually use simplexml if available (it's a php5 thing). I find the document object structure in simplexml to be pretty "drupal like". this would help a ton not only for rss/atom stuff, but for other webservices integration. as usual, if nobody beats me to it, it's something I'd love to contribute.. :P -- James Walker :: http://walkah.net/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 23 Sep 2005, at 2:06 PM, James Walker wrote:
In fact, I would like to see a general xml.inc for generalized XML parsing / generation - which then parse_feed could use to handle specifics of feed types. PEAR currently has a package in the proposal stage that does just this:
How about using Magpie ? Someone's already written this well once. - -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin) iD8DBQFDNBePgegMqdGlkasRAvAcAKCqdeIKi8O1c7LjF0PIARUUPiKA6QCgiGMn z6IfYz0eTbtbTotPyyV9RBs= =gS1s -----END PGP SIGNATURE-----
How about using Magpie ? Someone's already written this well once.
I believe someone already looked into this (mozillaman), and he seemed to think that there was no way it'd be possible to hook it into our cache system, nor was it substantially different from what we were doing now. -- Morbus Iff ( you are nothing without your robot car, NOTHING! ) Culture: http://www.disobey.com/ and http://www.gamegrene.com/ O'Reilly Author, Weblog, Cook: http://www.oreillynet.com/pub/au/779 icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus
If you're going to limit it to feeds, you can really let aggregator.module do its thing and utilize the results. I'm doing exactly that in an experiment right now. I've created a node type that essentially uses the aggregator_feed table as a table to hold node-specific information. If you're going to write an XML parser, I can't see how we could improve on what PHP provides. On 9/22/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
Hi there,
While updating naggregator.module, I decided to put all RDF parsing stuff in one parse_rdf.inc. Naggregator needs it, aggrgator.module, aggregator2.module and most probably more modules could use a general rss parser.
I would like to know if anyone wants to help me develop this. And I also would like to hear any suggestions. Questions I have been asking myself are: Should this maybe be a general XML parser.inc, rahter then only a rdf/rss parser? Should I include some general remote-file functions (I already have a general drupal_remote_file())
For now, what i have is loosely formatted after the mysql/database functions in PHP: rdf_get_object($res) rdf_get_array($res) where $res is a result (feed) returned by drupal_remote_file(); Both 'get' functions return one item a time, as object. similar to the 'row a time' the database functions to. On top of that, Id like to see a rdf_get_feed($res) which returns an object with an array ($object->items) containing all the items as objects.
Please let me know if you are interested in lending me a hand, or if you have other ideas about getting this in core. Or anything else.
Bèr
participants (5)
-
Adrian Rossouw -
Bèr Kessels -
Earl Dunovant -
James Walker -
Morbus Iff