Merc,
First off, I'd like to thank you for your contributions here at Drupal. You have created some great modules and think you've been doing a fantastic job thus far. As I'm sure you've noticed, I've been spending quite a bit of time on Driggs issue queue. The reason I've been spending so much time is to help your efforts in making Drigg an awesome module for the Drupal community.
One thing I think Drigg needs much improvement on is it's modularity. I scratch my head wondering how Drigg came to exist as a alternative to Pling. You must have seen some value in using Drupal verse having a stand-alone web application. To me, that value is the community.
Drupal isn't just a platform to build on. It is a whole community of developers who are working together to create modules which can be combined to provide an infinite amount of functionality. Drupal core only scratches the surface of all that is Drupal.
It seems like much of the work on Drigg has been to build on top of Drupal. I will give you credit on your use of Voting API, but that is about where the supported integration ends when it comes to other modules aside from the modules you maintain.
Your plan for the most used module, Views, only seems to be to make Drigg compatible but fear using it because of query performance (side note: do you know about the performance group). You admitted to not even hearing about CCK in this ticket. I'm not sure where the module was back in 2008, but now it is the 2nd most used module and is in d7 core.
One perfect example of Drigg's monolithic nature is the trackback functionality. Rather than using a module, you hard-coded it into Drigg. Now you are left having to manage the code, making Drigg and even larger beast to have to control. I know your going to hate me saying this, but this is the kind of move Microsoft continues to do. For many users, this functionality is just bloat because not everyone uses it.
I'm sure you have a perfectly acceptable explanation for the trackback issue. No need to defend yourself. I'm not criticizing your work, I'm just trying to offer some feedback to improve Drigg. Perhaps there wasn't a good module to provide trackback functionality. Maybe you were on a time crunch and just wanted to get the functionality in the easiest way you knew how.
The point isn't the specific issue. It's about the Drigg module's ability to use other modules to provide endless functionality. There is a big desire to use Radioactivity with Drigg. I've attempted to get drigg to use Views.
There are also much functionality in Drigg which can be handled by other modules. Recommender can replace Drigg Related Links module. Moderation can replace Drigg Approval Queue. And I'm sure there is a bunch more...
I'm not saying your code is bad, I just think your time will be better suited getting other modules to provide functionality to Drigg rather than trying to make every useful feature part of Drigg's code.
You've done quite a bit of work on Friendlist. I like how it has ended up! There is a clear list on the project page which show modules that play nice with Friendlist and offer some great functionality. I would like to see the same happen to Drigg.
You certainly don't want Drigg to be bloatware. Unfortunately, the only way to prevent it is to leverage the functionality in other modules. This way site developers can pick and choose the functionality they want in their site. This is what Drupal is all about.
It's not going to be the easiest approach, but it certainly is the best.
Comments
Comment #1
mercmobily commentedHi,
This issue is just too broad to be left open. But, it raises good points.
Quick roundup:
* Radioactivity had huge problems when we wrote the integration code back then. I had tons of reports of nodes being published for no reason. If it's stable, I agree that it would be a great contribution
* CCK cannot be used instead of the drigg-specific "drigg" because drigg _is_ essentially a node type. Its strength is in the submission form, which check if a URL works, for example. You _can_ use CCK with Drigg (well, in version 6 anyway)
* As far as Views, I explain why it's not pracrical here #481678: Use Views with Drigg UI . I also say clearly that I would be happy to get rid of drigg_ui if somebody managed to do what we do right now. But, I think it's very unlikely.
* Trackbacks -- I agree. I cannot remember why it wasn't OK back then, but I am all for it
* Recommender: as above. Absolutely
* Moderation: The way it works right now is quite neat. The moderation module does very little -- all it does is test for nodes with publishing time in the future. What a drigg-administator needs to do is very specific. But, if you show that the same thing can be done with a moderation module, then I am all for it.
* EVF. You forgot to mention it. EVF will soon have 0 open issues, it's a neat module that does the job nicely. I wrote it because Vote UP/Down , at the time, was plagued with hundreds of issues and bugs, and I ddn't feel I had the skills to fix it or even help. Now, we have EVF and there would be no point in killing it. Heck, you don't even have to use EVF if you don't want to! But I admit here that I reinvented the wheel.
* User Karma: Well, there was no workable Karma module for Drupal brfore User Karma. So, I invented a wheel that wasn't there :D
Friendlist was a glue module, and it was indeed possible to do a lot of stuf with Views etc.
I am going to close this issue, because I think we need to keep focussed and practical. But, just so that you know, I am not a fan of bloatware, and I will definitely prefer using existing projects. But, sometimes generic modules like views don't allow you do do specific things. And CCK would never allow you to do URL checking, submit-as if you have permissions, and so on.
But, thanks for the heads up and for helping out. Please keep things as practical as possible -- the more pragmatic we are, the more will get done.
Merc.
Comment #2
mercmobily commented