Make parser_csv_parse() into a parser class

Oh. And introduces the timeout parameter. Untested, but should probably work.

I'm completely fine with getting rid of custom code if there are no regressions in standards compliance. Didn't know the project on Google Code (I only made my way through the code comments in the PHP documentation). On first glance though, this specific project seems unsuitable to me in the current state as it uses PHP's fgetcsv() (which is not compliant to the CSV specification), and also it goes slightly against my personal needs as it doesn't take line iterators but only file paths. That's a direct consequence of using fgetcsv(), of course.

I don't want to impede the progress of this module though - if there are good reasons for switching to another parser (like speed, scalability or features) then I'll try to accommodate to it, or "fork" my iterator-based parser back to an implementation detail of my module. As long as using the one in parser_csv is feasible, I'll try to stick to it.

You also seem pretty committed to building a solid parser, so I don't have a reason for replacing it :-)

Well, as far as my needs are concerned I'm mainly done building it, no promises that I'll be further improving it a lot. (Although an output row iterator that avoids storing the full array in memory would be teh awesome. Maybe I'll try that still.)

However, I'm thinking that the CSV Parser portion of this project by itself could take advantage from being a Drupal independent project. You could use it in any PHP environment, right?

Right. On the one hand, that would increase the maintenance effort (file syncing, another repository to get and issue queue to subscribe to, can't depend on Drupal's Simpletest framework, etc.), assuming we stay the only project using the parser. But on the other hand we might gain more users (= contributors?) and also make it easier for Drupal modules to include just the parser in case they don't want to depend on or be part of the parser_csv package. Reasons for making the parser into a separate upstream are there, although I'm relatively indifferent whether to do this or not as the pros and cons pretty much seem to outweigh one another.

So what I'm thinking is we could make parser_csv a FeedAPI integration for an independent CSVParser project. I'm just wondering where we would host the CSVParser - any preferences? Google Code?

Google Code would also be ok, but my preference would be a hosting platform that does distributed version control systems. Like, say, Canonical's Launchpad - which uses Bazaar as VCS (including a very nice overview of private branches), bug tracking works ok, and unlike Google Code is going to go open source this summer. I've always wanted to try out Bazaar for real, it's the only major VCS that I haven't yet investigated in depth :P

I don't want to decide this all by myself though, your opinions and preferences are of course just as valuable as mine.

Either way, for now, I would like to commit this patch as-is.

I won't stop you from doing so, it's my patch after all :P