Update XML Parsing in update module

Yup. ;)

Cool, that's a good start. Some minor gripes:

A) Core patches should be generated from the root of the Drupal installation (where index.php lives). So, instead of this:

cd /path/to/drupal-7
cd modules/update
cvs diff -up > 324443_update_xml_parser.4.patch

You want this:

cd /path/to/drupal-7
cvs diff -up modules/update > 324443_update_xml_parser.4.patch

B) The function name should be [module]_[verb]_[noun](). So, instead of calling the function "update_xml_parser" (which made sense as a class name, but not as a function name), it should be update_parse_xml().

C) Code style: foreach(...) needs a space between "foreach" and the parens, like so: foreach (...).

D) Code style: if(...) needs a space after "if", like so: if (...)

E) The PHPdoc comment is incomplete, since the params and return value aren't documented.

F) I'm not sure $parsed_xml is the best name for that variable.

Otherwise, it looks pretty straight forward and works with my light testing.

Like so...

Removed a stray newline I left in there, and fixed the PHPdoc comment a bit to match the core grammar style for that initial verb.

Not sure this is an improvement over #6, but here's another option to consider. In other parts of the update.module codebase, that nested array of parsed data about available releases for each project is called $available. Even though from the perspective of this particular function, $data might make more sense, globally, it might help people grok the code to see the same name for that array as we parse and construct it. So, here's #6 after performing s/data/available/ ;)

Yay this should probably help speed up the update code a little since we're going to be using native parsing! Following...

Parsing the XML only happens when we download it, then the results are cached. This usually happens once a day, or maybe once a week. Performance is not a concern. The reason this patch is a good idea is because it rips out many lines of gnarly code and replaces it with something easier to understand. Furthermore, I bet this parser wouldn't have choked on the slightly different XML as a result of #157514-47: Add possibility to retrieve a list of projects from the server (see also #269444: Some xml information being lost by parser). So, this is less code, more easily understood, and (presumably) more robust. If it's a little faster, great, but I don't think it's even worth profiling, since this runs so infrequently.

I didn't know that you can link to a particular followup using that issue filter. nifty.

Works, looks good, committed. Thanks Derek.

Glad to help, though cyberswat should have gotten credit in the commit message, too... oh well. Thanks for committing, anyway. ;)