As we talked in the IRC, i told you i will help with the project_api and the drush_make_builder.

After studiing the code of the project API i was stumbling uppon limitations which are complete show-stoppers for me.

1. You cant handle multiple sources and no overlays. Its not possible to have a module with the same name from different sources ( thats what an overlay means). This is pretty important for the drush make builder if you include your own feature server to be part of the party and you want to select between the views module of d.o and the one of your server etc.

2. No support for feature server ( well that could be easy implemented though, but still the multi-source limitation )

3. the database structure in general is limited for multi-sources

4. There is no implementation of fetching all projects informations like releases and so forth. In general the fetching process is pretty hard to extend, you would need to reimplement it. Thats why i have chosen a OOP architecture.

Iam not writing down those things to stop on your toes - not at all. I just want to make sure that you know, i looked at your module and not just "started a new one".

In general the module is still in the early phases, rather unfinished yet, what is fine. But out of the archtictural reasons and the current status i decided to make a complete rewrite. The idea behind the project is _exactly_ the same, even with a larger scope.

I think update_feed_api is more complete now then project_api is, i have implemented a lot of things the last past days. I also added the documentation.

So my question is, why should we have 2 projects of this type, especially if it is an API for the same thing. Just let me know how you think about.
The current project can be found under - documentation is also quiet far already.


EugenMayer’s picture

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.

greg.harvey’s picture

Hi - completely agree - this was a rough and ready first shot with the specific goal of getting Drush Make Builder up and running to be re-factored later.

So, yes to everything you say. There is no formal release of this project yet and, as far as I'm concerned, the architecture is still very much open for discussion, as it's just a quick and dirty port of the useful bits from Plugin Manager (that's where the schema is lifted from too).

So, what I *do* have here is a project page and CVS namespace. Want to co-maintain and bring your code in? I'm not sure whether to make a branch or just ignore the original code and copy straight over it.

Let me know how you want to proceed, but you have my full support anyway. =)

EugenMayer’s picture

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 ).

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

greg.harvey’s picture

Ok - all sounds great. Regarding your reimplementation points:

1. Not everyone will want to use nodes. I spoke to at least one performance expert who said they specifically would NOT want the repo data to be nodes, as this crossed my mind too so I asked around. Better would be to allow hooks to alter the storage mechanism - see this issue in the Feedback module I'm working on for example of what I mean:
#293512: Abstract back-end for integration with 3rd party issue trackers
I think we should *start* with the concept of powering storage mechanisms via hooks so people can write their own (which might include storing the data in a totally separate system if they want!) - that way no one is tied to node storage - some people will want it, some specifically will not.

2. Awesome! =)

3. That makes sense ... but I would leave the textarea on edit, even if only available to administrators, because that's a 'get out of jail' sometimes.

I have no problem with using your name instead. We should set up a Drupal project and check your code in to CVS asap... We should probably take update_feed_api as the namespace in CVS and put update_feed_cck in a contrib/update_feed_cck directory within that project. Ditto with views_select - I would rename it update_feed_views_select (if that's not too difficult) and put it in the contrib directory of the update_feed_api module and we should just create a Package name for the set.

As for drush_make_builder, it is already quite well publicised, so why don't I just make you a co-maintainer and you can commit your code there. I am normally comfortable with over-writing -dev code, but I don't want to piss people off if they are already experimenting with the dev snapshot. "Well don't do that then" is an ok response if people used a snapshot, but at the same time, if you annoy people they can just think the project is being maintained by cowboys and never use it again. So perhaps we should branch anyway and put your code in a 6.x-2.x branch. Thoughts?

In other news, q0rban ( who makes Profiler is interested in joining forces to build a killer platform based on all three projects. Hopefully he'll jump in here too.

I'm pretty excited about all this! =)

EugenMayer’s picture

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.

As i used a complete new implementation type ( Features / CCK/ Views ..) i created the module under drush_make_ui on 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

greg.harvey’s picture

1. Fair enough. Your argument is far more compelling than the counter. ;-)

Didn't realise you already have a project for drush_make_ui - wish I'd seen it before I made drush_make_builder! Oh well. Glad we're on the same page now.

EugenMayer’s picture

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.

q0rban’s picture

q0rban’s picture

So what's the consensus here. Moving work from update_feed_api and drush_make_ui into drush_make_builder and project_api? I haven't had a chance to try out either, but I'm very interested in the project. :)

EugenMayer’s picture

Actually we have 3 new projects on, 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.

greg.harvey’s picture

I've just started on a big project which is sucking all my time, so I haven't had chance to check out Eugene's work properly, but since mine was a hurried 'port' of the useful bits of another module in to an API + the beginnings of an interface, Eugene's sounds further down the line. The code I started with has architectural flaws, as Eugene has already pointed out - if his already circumvents this then it makes little sense to work on revising mine. It's simply a case of deciding which namespaces to use in and continuing with Eugene's code, I think.

The only thing I'd like to do is make sure Eugene's code exposes enough of an API that projects such as the Plugin Manager module can plug in to the repo management bit. This I have not had time to review, but since we have similar goals it probably does.

EugenMayer’s picture

It does :) Much more then your current implementation does. Just check
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.

EugenMayer’s picture

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.harvey’s picture

Status: Active » Fixed

Ok, I'm fine with that. Will close releases/re-point project pages/apply to have them removed.

@q0rban, direct your interest to Eugene's modules! They represent a better start. =)

EugenMayer’s picture

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

greg.harvey’s picture

Thanks, will do. It will be several weeks because of the project I'm currently on, but definitely want to get involved. =)

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.