[development] PHP 5 > aggregator.module rewrite to XML API?

Alexander Barth alex at developmentseed.org
Tue Jun 19 21:35:51 UTC 2007


Tuesday, June 19, 2007, 4:08:30 PM, you wrote:

> Ahhh... so by sanitizing you mean accepting non-fully standards
> compliant feeds? If that's what you mean then definitely not. I
> totally agree with Larry on this. Why waste my processing time on
> feeds that are not worth a penny?

I think the very discussion that we are having here is proving that
there are use cases where you want to go for speed rather than
resilience, and there are equally valid use cases where resilience is
more important than speed. I guess we'll find contradicting use cases
like these all the way down Aggregation Lane. We shouldn't get caught
up in discussing which one's the one. The new aggregator should
provide a fundament that does what all aggregators have to do while
leaving all doors for improvement and adaption open.

> Also, in my issue queue I haven't received one complaint about a
> feed that would not parse. Not because I do any sanitization, but I
> think the reason for this is because I parse the feed as an XML and
> look for the main components, so even if it's not fully conforming
> it will make do if it has the main components. If it's beyond hope
> in being called XML in the first place or just totally messed up I
> don't waste the time and the coding effort that might double or
> triple my module's code size on it. If that's a type of sanitization
> then good for me but it definitely does not affect my module's
> performance :-)

Aside:
I was just looking at aggregation module and I like how it keeps XML
parsing and parsing into your internal data structure apart.
How did you decide on the data structure that you use in
aggregation?

>  Finally, I don't really care to make my module work with everyone
> and everything. That's why I have clear PHP 5 and CURL requirements.

Agreed. There won't be a "one single monolithic module serves
all" solution. I do hope though that there will be a "one fundament/API
serves them all" solution.

* We are duplicating efforts between all aggregation modules that have
nothing to do with the special requirements which justify every single
module out there.
* A lot of features that are implemented on just one aggregation module
would be good to see on all aggregation modules.

Alex


  


-- 
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 



More information about the development mailing list