Complete re-implementation of project_api for being widely usable

I also added an administration / configuration interface and added a batch API approach with an UI. Daniel wrote an Views integration.
You can already load / store / search for projects using the API, listing available API versions for a projects and all of those things we will need for drush_make_builder.

Well update_feed_api is pretty done already and i have written a CCK integration today (for drush_make_ui).

As you see, i have also reimplemented drush_make_builder after looking at its architecture:
1. Iam not sure why you did not use a node for a make file. By doing this, i have a integration with CCK, Views ,Taxonomy and all the other nice things of node. This makes a huge sense when you later work with all those make files or especially build relationships (easy with node-reference). The code-size reduces a lot and also the whole data-storage/reading/updating is just given bugfree from the nodeapi.
2. I have written the cck field (update_feed_cck) to be able to map a module to a node (out of the feed). This is a classical CCK integration and can have several widgets on the same data - very handy and later on very powerful to build different UI`s
3. I also decided to not go for the "paste result into textarea apporach". Eventhough it has quiet some handy things ( you can customize it right away or just write entries your way), it kind if destroys the effort and use i see in the drush_make_builder. Beside you can use the UI to build the make file, the most important advantage you get compared to the classical ones ist, that you can later use views and those integration to check, which make file has updates. Making make files relate to "customer" this gives you very nice integrations. So losing the "structure" is very sensitive and thats why i decided to implement a compounded CCK field which saves server_key, short_name, api, release as single db fields, making them directly accessable in views and filters.

Iam feeling pretty uncompfortable to actually create 2 new modules instead of helping you with your 2, but somehow i would have rewritten the module due to archticture-flaws (from my perspective . the use case i see). And providing a huge patch is just kind of "rude".

So dont get me wrong, iam very much interested in sharing all those and working together but i just aimed to have a good base to start from as this thing will be one of the heartpieces of my maintainance architecture.

I dont think it makes too much sense renaming update_feed_api and update_feed_cck again, its quiet deeply coded in, we will probably waste quiet some hourse on this (all the database tables, views integration ...). Would you mind just using the "new name" instead?

For the drush_make_ui / drush_make_builder, well this one is still pretty "fresh" and small so i can easily rename it ( if you are interested at all of course ). http://github.com/EugenMayer/drush_make_ui.

I have also written a helperplugin for views to use the views-integration of update_feed_api called "views_select" (http://github.com/EugenMayer/views_select) which actually gives us a quick aproach for "searching and filtering all projects and selecting them".

1. Well actually, this makes absotely no sense. Iam not storing the _modules_ or releases, iam storing the make files as nodes. That means that you have < 50 nodes. There is absolutely no reason to implement a other backend here.

drush_make_builder:
As i used a complete new implementation type ( Features / CCK/ Views ..) i created the module under drush_make_ui on d.org already. I will link back to your module and state that we work together. When we actually have a result on all those storages and thinks we can decide which appraoch is better.

Iam also glad we can join forces. Currently i have put a lot of time into all this and i could really need some help

drush_make_ui has been created after drush_make_builder even. Its not older then a few hours.

For me this one is fixed, iam glad we will merge all the work together. If you want to work on any of those modules, just give me a hint, you get github access on the fly.

Actually we have 3 new projects on drupal.org, update_feed_api , update_feed_cck and drush_make_ui .

Right now i tend to keep those 3 modules, at least it will be that way for the api and cck. Iam still not sure for drush_make_ui, but tend to keep the module as is.

It does :) Much more then your current implementation does. Just check update_feed_api.api.inc
In addition, you can work the OOP way with the factories and project/ release classes.

How the API can be used is demonstrated in the update_feed_cck widget.

Well just to end the discussion here. I have decided to keep the current names, so update_feed_api and drush_make_ui.

So if you want to join forces you might want to link over the project or continue here if you want to keep on project_api / drush_make_builder.

Greg when you find time to help with those modules, let me know. I will grant you access.