First off, thanks for creating this project. I am working on the Drush Make Builder module, which allows users to create make files dynamically. I was pointed towards your module in #927508: Allow choosing of modules and themes by pulling in list from Drupal.org while looking in to a way to draw all the project data down from Drupal.org. At first I toyed with making your module a dependency, but this would be silly because I only needed two functions and some of your database structure.

Then I toyed with writing some core API functions, but I figured it was nothing to do with core and they would never make it in (and rightly).

Then I thought maybe I could ask you to split the API bits I needed in to a separate contrib module in the Plugin Manager package, but then again, people will still have to download the whole Plugin Manager package to access just the ability to save and manipulate project data locally.

So instead I created this:
http://drupal.org/project/project_api

The README goes in to a bit more detail about the thinking:
http://drupalcode.org/viewvc/drupal/contributions/modules/project_api/RE...

As you can tell, I have borrowed a lot from the design of Plugin Manager (which I hope you feel has been sufficiently credited to yourself, both in the README, in-line docs and the project page). So, having created the Project API it would make sense if modules needing to achieve a similar goal (e.g. Plugin Manager and surely others) extended the features of the Project API in line with their needs.

I appreciate this is a bit of a surprise, and don't seek to make work for you, but it would be awesome if you can plug in my work to date so you can use the Project API too. That way you and I can continue to developer the Project API together, as a joint dependency for two separate projects.

I've also made Project API so the repository is pluggable. The core repository, provided with the module, is Drupal CVS (pretty much as plugin_manager-6.x-1.10 has it) but it's perfectly possible for people to create a repository module for a features server or for something entirely separate like Sourceforge.

Anyway, let me know what you think. =)

Comments

Anonymous’s picture

Anonymous (not verified) commented

I like it. :)

In 6.x-2.x one of the things that I've been working on is the ability to use multiple back-ends. I had been planning to use that with a side project of mine: Adparo. At the moment it is in an unpolished state, though it is getting much closer. Still, it might be of some use to you. It's been designed to overcome many of the issues that I faced while trying to get project data.

Adparo (adparoproject.com) aims to provide a Wikipedia style interface for Drupal project information. Amongst other things, it will provide smaller, cleaner XML files, specific to the API version. More importantly however, it will provide a public XML-RPC interface that will allow full-text searching of projects along with data retrieval of ALL available project information (including description). I'm just getting ready to add that capability to 6.x-2.x. Would this be of any use to you as well?

greg.harvey’s picture

greg.harvey
Primary language English
Location Occitanie, France
commented

Absolutely! Sounds awesome... could definitely do with your expertise in ironing out the kinks in Project API, and if you were prepared to use it as the repo back-end for Plugin Manager's new branch, that would certainly boost the pace of development and (hopefully) save us both some time. Certainly since we both want multiple repos, that's a great starting point. I need to look at your 6.x-2.x code, as I have not had chance yet. I worked from your stable branch for now to create the first release of Project API.

Adparo sounds cool too. When things are ready, an Adparo plugin module (like project_api_drupal.module that comes with Project API) would be perfect, to allow people to opt to get their data from Adparo instead of Drupal.org if they so wish. You see, that's the idea behind Project API. People should be able to write a module that plugs in any old repo and Drupal should store the repo data in a normalised way. I suspect the Project API database schema could already do with a re-think, but I'll tackle that next time someone wants to create an additional plug-in that will require some new columns.

So, to summarise:

1. Any work you're doing regarding multi-repo support would be gratefully received in Project API and (if you're willing) using Project API for Plugin Manager's back-end would be amazing. If you need to patch Project API to make this work, I'm happy to work with you to that end.

2. An Adparo plugin module, when the time is right, would also be amazing. It would show the 'pluggability' of Project API. Someone else is working on one for a Features server already, I think.

On a side point, re: XML-RPC on Adparo, you probably know this already - but have you used Services before? Making a new service is really easy via the API and once you've done so you're not restricted to XML-RPC - you can use any of the 'server' modules! (JSON, SOAP, REST, etc. etc.) It's well worth checking out for Adparo's API - will allow you much more flexibility:
http://drupal.org/project/services