add1sun suggested me in IRC to post this question in the development list: I have an idea for a new module/project that would merge the functionality of approx. six different modules into one API-like module. There's no code yet, just the idea. Would it be too rude to already create the project on d.o, primarily to invite others to join and contribute to the project? I was thinking of this to protect the generic project namespace, because it is not yet occupied and IMHO it should be reserved for such an API module. Personally I don't like project registrations for modules that do not yet exist. However, there has been a similar case in the past with the "file" module/project/namespace. IIRC, it was used by an E-Commerce contrib module, which was useful for specific use-cases, but was not an API-like module for integration with other modules. Today I'm getting an Access Denied error on http://drupal.org/project/file, but that is *not* the point - I think you get the idea. The amount of contrib modules is constantly increasing. IMHO it is important for Drupal to reserve certain generic names for API extensions or even Drupal core extensions. On the other side, it obviously makes no sense to reserve any generic namespace, if there is neither an idea nor code existent. However, in this case there is an idea and most of the code could be merged from existing modules. Of course, the idea is not top-secret and I could have boiled this issue down to that particular case description. However, I would like to hear the basical opinion of the developer community, which might be added to the handbook pages, too. sun
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Daniel F. Kudwien schrieb:
add1sun suggested me in IRC to post this question in the development list:
I have an idea for a new module/project that would merge the functionality of approx. six different modules into one API-like module. There's no code yet, just the idea. Would it be too rude to already create the project on d.o, primarily to invite others to join and contribute to the project?
I was thinking of this to protect the generic project namespace, because it is not yet occupied and IMHO it should be reserved for such an API module. Personally I don't like project registrations for modules that do not yet exist. However, there has been a similar case in the past with the "file" module/project/namespace. IIRC, it was used by an E-Commerce contrib module, which was useful for specific use-cases, but was not an API-like module for integration with other modules. Today I'm getting an Access Denied error on http://drupal.org/project/file, but that is *not* the point - I think you get the idea.
The amount of contrib modules is constantly increasing. IMHO it is important for Drupal to reserve certain generic names for API extensions or even Drupal core extensions. On the other side, it obviously makes no sense to reserve any generic namespace, if there is neither an idea nor code existent. However, in this case there is an idea and most of the code could be merged from existing modules.
Of course, the idea is not top-secret and I could have boiled this issue down to that particular case description. However, I would like to hear the basical opinion of the developer community, which might be added to the handbook pages, too.
Can't you simply sit down on the weekend and create somethign that resembles code and check that in? Problem solved. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG1yDLfg6TFvELooQRAl6fAKC3va6WtHEfdgqJL1nrSLxm5082EQCdFhcU 9/URccu1v91dX6Bx6azJbKQ= =86CR -----END PGP SIGNATURE-----
On 8/30/07, Daniel F. Kudwien <news@unleashedmind.com> wrote:
add1sun suggested me in IRC to post this question in the development list:
I have an idea for a new module/project that would merge the functionality of approx. six different modules into one API-like module. There's no code yet, just the idea. Would it be too rude to already create the project on d.o, primarily to invite others to join and contribute to the project?
Modules are good because they are modular. What is the advantage of putting 6 into one? -- Neil Drumm http://delocalizedham.com
Modules are good because they are modular. What is the advantage of putting 6 into one?
The existent modules do not share the same data, although all of them deal with the same kind of information. AFAIK, most of them implement their own forms to fetch and output similar data and do not interoperate with other modules. Thus, an API(-like) module would not only reserve the generic namespace but also introduce a shared, extensible dataset. That was the good news. The bad news is, that there is no code and I will not have time to actually do something within the next weeks, which in turn is the (hopefully reasonable) cause for my question. sun
On 8/31/07, Daniel F. Kudwien <news@unleashedmind.com> wrote:
Modules are good because they are modular. What is the advantage of putting 6 into one?
The existent modules do not share the same data, although all of them deal with the same kind of information. AFAIK, most of them implement their own forms to fetch and output similar data and do not interoperate with other modules. Thus, an API(-like) module would not only reserve the generic namespace but also introduce a shared, extensible dataset.
From the description, the name 'drupal' comes to mind for that module, but it is already taken by a core module. ;-)
Joking aside, not much can be said before hearing something specific about this module, anything.
That was the good news. The bad news is, that there is no code and I will not have time to actually do something within the next weeks, which in turn is the (hopefully reasonable) cause for my question.
sun
This discussion is a bit pointless unless you can elaborate on what your new module might be doing. As killes said - if you really think you want it, create a project, commit some skeleton/"hello world" code, and get back to use when you have something meaningful to share. -Peter On 8/30/07, Daniel F. Kudwien <news@unleashedmind.com> wrote:
Modules are good because they are modular. What is the advantage of putting 6 into one?
The existent modules do not share the same data, although all of them deal with the same kind of information. AFAIK, most of them implement their own forms to fetch and output similar data and do not interoperate with other modules. Thus, an API(-like) module would not only reserve the generic namespace but also introduce a shared, extensible dataset.
That was the good news. The bad news is, that there is no code and I will not have time to actually do something within the next weeks, which in turn is the (hopefully reasonable) cause for my question.
sun
I think we have a gap here. On one end the original poster is saying "I have an idea to merge 6 modules" but nothing specific on what the megamodule will do or what it will replace or what the benefits of 1 vs 6. On the other hand, we have the old "code is golden" motto, where we want to see the code. Two middleground options are better: The first is to explain what these 6 modules are, why combining them into 1 is better, and how is this better for everyone in more detail. Once we have that, you can get feedback before you write code. The second is to quickly prototype what is in your head, just check the code in your sandbox at cvs.drupal.org, without creating a formal project for it, then seek feedback on it. Both of these options save you time, as well as everyone else.
participants (7)
-
Cog Rusty -
Daniel F. Kudwien -
David Strauss -
Gerhard Killesreiter -
Khalid Baheyeldin -
Neil Drumm -
Peter Wolanin