7. If I had had check_plain() drupal_http_request() valid_url() my code would be shorter now and I could have written it in less time.
8. RSS/Atom parser RDF parser OAuth Activity Streams Saman Pub/sub Ever more jQuery for UI Some existing challenges that will benefit form good external library support:
9.
Notes de l'éditeur
Much of the code we are maintaining in Drupal today isn’t actually Drupal specific.
All these are functions or libraries that are either external libraries or that could very easily be part of an external library. None of them is Drupal-specific.
Recently we found a series of problems with Drupal’s OpenID implementation. We should share our implementation with other projects to minimize these sorts of glitches.
It would be not just beneficial to use more of other project’s code but to also make Drupal’s code available to other projects where it makes sense. Consider this example. I have written a PubsubHubbub subscriber and hub in a non-Drupal specific manner. In a nascent technology like PubsubHubbub it is crucial to share on the lowest common denominator: in this case, PHP. It was actually easy to write the library Drupal independent, but it was also a pain not to be able to rely on Drupal’s convenient library: drupal_http_request(), valid_url(), check_plain().
I couldn’t use any of the useful Drupal helper functions like check_plain() although they’re is no reason why they would be Drupal specific.
The application layer on the web is getting shaped by more and more standards and common best practices. We can’t afford to have a Drupal-only implementation for all of them. We need to get better in integrating with non-Drupal specific code. Let’s open the doors.