Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Nokogiri response parser if applicable / available, fall back to pure ruby. #7

Open
briandunn opened this issue Jul 24, 2010 · 2 comments

Comments

@briandunn
Copy link
Contributor

Actually I'm cool with Nokogiri as a dep, but in order to fulfill our pledge of pure rubyness...

Given I search
And the server responds with compact decoded xml
And nokogiri is installed
Then the response should be parsed really fast, yielding between rows

Given I search
And the server responds with a different type
Then the response should be parsed slowly and purely.

Given I search
And the server responds with compact decoded xml
And the gem "nokogiri" is not available
Then the response should be parsed slowly and purely.

Is that what you had in mind, josephholsten?

@kidbrax
Copy link
Contributor

kidbrax commented Dec 17, 2010

I was wondering about this as well. I just had a feed that kept choking because apparently the RETS tag wasn't being closed. I switched all the parsing to Nokogiri and was able to get past the problem. So I was just wondering if there was any reason to not move all the parsing to Nokogiri?

@briandunn
Copy link
Contributor Author

This is a branding thing. We want to stay true to the "4R" part of the name: ideally the only dependencies would also be in pure ruby.

Ideals aside, Nokogiri is awesome, and libxml ubiquitous. We should implement the automatic use of nokogiri where available. Tested pull requests welcome. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants