Consider creating a separate project for the discography framework

Deciding whether to do this is probably my #1 priority right now. If it happens, it should happen soon, before the 7.x version is widely adopted.

If I were to do it, here's how I would break up the modules:

• The Release Node, Track Node, and Track Field would all go into the (currently unused) Discography namespace as a separate project.
• The Discography Mediator would be its own project with its own namespace.
• The Discogs.org Adapter would stay at the current Discogs namespace.
• I am unsure where the Release Adapter should go. Make it its own project (the ideal solution)? Make it part of the current Discogs project? Put it under the Discography namespace?

The major advantage to this arrangement is that users, developers, and Drupal distributors could pick and choose which modules they wanted and which they didn't. (It may be possible to do this already using Features, but I've never actually used that, so I don't know.)

The major disadvantage is that current users would have a more complicated install process. They'd need to download a whole slew of different modules to get the same functionality that they had in a single module in the 6.x version.

Another change would be separate issue queues for each of the different parts of the framework. That would work out great for me, but it would probably be confusing for users.

One more issue would be the upgrade path, but any simple solution to that is already shot to hell. I doubt this would make it any more complicated.

I would like to hear current users chime in on this as well. I will probably send emails directly to those who have contacted me, but I want to hear from everyone who used the module, and/or may use it in the future.

Also, keep in mind that this may be frowned upon by Drupal.org maintainers. The two Drupal people I've managed to talk to on IRC both said to just leave it as is, but they're not actually site maintainers, and they didn't phrase it as if it were a rule (more like advice). I'll have to dig up more information about this.

Addendum: I thought of one more benefit to separating modules.

The Discogs.com API actually provides a lot more functionality than just getting discography information. For example, you can get Discogs.com user profiles, or information about albums for sale in the marketplace.

Now, this is all pretty useless for someone who wants to simply import discographies. It might be useful, however, for someone who wants to do something like integrate the Discogs.com marketplace with Drupal Commerce, or integrate Discogs.com users with the site's user profiles.

Modules that do this would best be put under the umbrella of the Discogs project. Essentially, Discogs would become a "suite" of tools for interacting the Discogs.com API, each tool being a separate module that can be enabled on demand. Integrating discography info would simply be one of those tools.

I'm not suggesting that I'm qualified to write all those tools, I'm just saying it's an interesting idea.

IMO, I don't think this is a good idea. Right now you have focus. The name of the module is Discogs. The module imports information from Discogs.com API. This is very clear and easy to understand, and it does what you expect. You can add adapters to allow mapping Discogs.com info to other projects which is very useful.

Breaking things up would add unnecessary confusion and make things harder to understand.

Additionally I think your concept of a "discography framework" is somewhat different than Pushtape's concept of a "discography framework" (see Pushtape_Discography) and will confuse many Drupal users. I think we need to explicitly define what we both mean here. From my perspective, I see your work almost like a Discography API that focuses on importing and mapping. Pushtape provides structure that things can be mapped to.

My suggestion is to keep things as they are, for now.

Breaking things up would add unnecessary confusion and make things harder to understand.

This is a very good point, and it's definitely related to the downsides I mentioned earlier.

My focus with 7.x was to make it easier for other module developers to get involved, by creating adapters. I deliberately chose the names "adapter" and "mediator" because these are well-known design patterns in software engineering, so that developers would better understand exactly what is going on. Of course, users generally aren't developers. You're probably right that this would only confuse them.

The other point was to make it have a broader reach; to not have it exclusively associated with Discogs.com. For example, early on, I was hoping to get the author of the Spotify module involved. But that doesn't seem to have gone anywhere, so I don't know how much interest there is among other module authors.

As an example: I assumed that breaking up the modules into different projects would benefit people like you, but if you don't think it's a good idea, then obviously that was a bad assumption.

...In any case, the vote so far is 1 for, 1 against. Hopefully more people will chime in.

EDIT: My original opinion was that things should remain as-is, but upon reflection, I'm very much on the fence about this. I know I'm flip-flopping here, but it really is something that I'm having a hard time deciding. The "user" in me wants things to stay as is, but the "programmer" in me wants it separated.

We definitely need more people to voice their opinions - most especially users.

It *could* benefit people like me, but it's possible I am not understanding what your ultimate goal is - a complete solution? Toolkit?

Couple follow up questions:

• How are you defining what a discography is?
• What is the scope of your interests/maintenance?
• What are the use cases? Is there a list of adapters beyond discogs.com? If the list is short, maybe all the adapters can be grouped in one project.
• Why define release and track nodes at all - why not just let users set these up?
• Discography Mediator seems like the core module in all of this. Is there way these projects can be structured in a [core module]_[submodule] namespace pattern? (i.e. media, media_soundcloud)

Excellent post #4, I agree completely. Let's keep it simple, and focused on Discogs.

Why define release and track nodes at all - why not just let users set these up?

Very good point.

Zirafa:

It *could* benefit people like me, but it's possible I am not understanding what your ultimate goal is - a complete solution? Toolkit?

As the project evolved, there feature requests that kept popping up. Mainly, people wanted to get info from places other than Discogs.com, and they wanted integration with other projects (yours, for example). This can really only be done if the project is some kind of framework. (Or toolkit, if you prefer.)

But the 6.x version was more of a complete solution, and I absolutely need to support those users as well. (I'm still trying to figure out how to code the upgrade path...)

To answer your specific questions:

How are you defining what a discography is?

You mean conceptually, or in terms of Drupal modules? Conceptually, it's metadata about a unified collection of songs, including metadata about those songs. In terms of Drupal modules, the 6.x version had a (relatively simple) Discogs node type, that included everything. However, the fact that people also wanted to use the songs separately led me to create the types there are now.

What is the scope of your interests/maintenance?

Well, I'm it, at the moment. I would love it if other people wanted to co-maintain, and part of the reason that I wanted to make it a framework was to open it up to other developers, and possibly take some of the weight off my shoulders. (I'm back in college full-time, so don't have a lot of time to spend on this during the semesters.)

What are the use cases? Is there a list of adapters beyond discogs.com? If the list is short, maybe all the adapters can be grouped in one project.

Provider adapters? Yes, at the moment, Discogs.com is it. I've just taken a look at the Spotify API, though, and I think writing a module for that should be fairly simple. (I was hoping the author of the Spotify module might be into helping, but he seems to have disappeared.) Other people have requested Last.fm and MusicBrainz.

Why define release and track nodes at all - why not just let users set these up?

First of all, it's less convenient for most of the users. An out-of-the-box solution is what I gave them in 6.x, and it's what they're used to.

But, it's also a practical necessity. If the user imports info from a third party (Discogs.com right now), then how is the module supposed to know how to store that data in the user's content type? What fields does this type contain? Is it even a node type, or some other entity type? How are tracks handled - as a custom field type, a different node (or other entity) type, or even just a single text field with multiple instances? If tracks are separate entities, how are they "connected" to the release type - Relation, Entity Reference, References, Node Reference Create, or some other way? Is there even a "release type" to connect to?

Defining release and track nodes is the only way to know the answers to these questions. Simply handling all the image modules in 6.x was bad enough, there's no way that handling user-created discography types would be on the menu.

But, I did want this ability to be present, which is why I made it possible to create Entity Adapters. They must be programmed, and can't be set up by the user, but at least it's a step in the right direction.

Discography Mediator seems like the core module in all of this. Is there way these projects can be structured in a [core module]_[submodule] namespace pattern? (i.e. media, media_soundcloud)

I actually didn't know that this was a namespace pattern. I did kind of do this, in the sense that all modules start with "discog". The suggested namespaces simply make sense (to me at least), and keep function names short.

EDIT: Actually, I get what you're saying a bit better now. Providers and Entities don't have much naming overlap, so simply calling them "discog_whatever" would be acceptable.

For example, the Discogs.com provider adapter would be discog_discogs, a provider adapter for Last.fm would be discog_last_fm, and the entity adapter for Pushtape Discography would be discog_pushtape.

This actually sounds pretty good. The only issue would be changing the names of the current modules.

On the other hand, there are no naming restrictions at all on the module names, even now. The adapter (of either type) implements an info hook, and that's how the Discography Mediator gets all of its information about the adapter. So, if you wanted to name a provider adapter something like "discog_soundcloud", nothing is stopping you. Heck, you could just name it "soundcloud," and it would probably work.

...By the way, that's another reason I wanted to structure things this way. Existing modules could be adaptable to the Discography framework simply by putting in a couple of hooks in their own modules. If there were a general-purpose Soundcloud module, for example, that module's developers could just implement a couple of hooks, put it with the rest of the code in their module, and et voila - their module is an adapter. They could even add those hooks to the media_soundcloud module if they wanted (though I don't think this would make much sense myself).

Does this all make sense?

I agree completely. Let's keep it simple, and focused on Discogs.

So, that's now 2-1 for the decision to keep things as is. (I am officially abstaining.)

Just FYI, the point at which this project is exclusively about Discogs.com is long passed. Obviously Discogs.com is going to be supported, perhaps even the primary focus, but there will certainly be other providers available soon.

Zirafa's suggestion about the naming conventions is a good one. (It's the last thing on the list in #6.)

I have created a separate issue for it: #2052127: Consistent Sub-module Naming.

This will mean renaming the discogs_prov module to discog_discogs, and the pushtape_discography_adpt module to discog_pushtape.

Thus, all you current users will need to delete the old modules, or else you'll get conflicts.

...See, I really should have worked all of this out before I even started coding the 7.x version. But there are no guidelines for this sort of thing at all.

The only other person who has contacted me is from someone who can't upgrade to Drupal 7 anyway, so he didn't really weigh in.

And, yeah, the entire point of this exercise was to broaden the image of the module to more than just the Discogs website. It looks like that might never work. I am writing an adapter for Spotify, though, so maybe that will help.

In any case, it looks like things are staying as-is for the time being.

Karl,

Thanks for your detailed responses. I think it's really important to think about the maintenance aspect. Simply splitting up the project won't necessarily make it easier to maintain (I think it would make it harder). It's also hard to base project structure purely on speculation about how developers may or may not extend it or help maintain it. If it ain't broke, etc.

I see the dilemma you are facing though - you created some good functionality around discogs.com and see potential to expand the concept of entity and provider adapters. However, in order to reduce the potential confusion of a complete restructure, you can introduce your idea slowly to people so they can understand the change and have time to adapt.

Maybe the first step could be to pull out the core utility module in all of this - discography mediator - and give it the official discography namespace, raising its status above discogs. Have the discogs module depend on it, but otherwise leave discogs as it is and with its current namespace and submodules.

With this minimal amount of restructuring, you would introduce the idea of making entity and provider adapters with only one dependency - the discography module.

Lastly, I have to again insist on not using the word framework - I think toolkit or API is much more accurate. The goal is to create a flexible Discography API for Drupal.

adding some links

So, the Discogs project is staying in its current form.

Any related modules (e.g. the Pushtape adapter, or a Spotify adapter) will go into separate projects moving forward, but the modules that are here will stay here. Related modules will be listed on the Discogs project page.

This seems to be the best solution, from what I've been able to gather.