Will this two modules become just one module one day ? And provide generic solutions both for admin and users queues or any other queues ?

Comments

ezra-g’s picture

ezra-g commented
Status: Active » Fixed

There is no intention on the part of any the maintainers for either module to merge. This was addressed by quicksketch at http://drupal.org/node/311497#comment-1023058.

julma’s picture

julma commented

Yes but now there is your module smart queue by user http://drupal.org/project/smartqueue_users

So maybe it is good time to raise the question.

I don't think we need several modules to do "queue".

Instead we could have a more MVC architecture with "nodequeue" or even renamed it "queue" for the model, Views for the display and other modules to add controllers.

ezra-g’s picture

ezra-g commented

The fundamental point in quicksketch's post was that the flag module sets a node as 'flagged' or 'unflagged' but does not control the ordering of arbitrary nodes, which nodequeue does. Other modules are free to interact with queues programatically, views already handles the display of queues, so I'm not sure specifically how you propose modifying nodequeue to be "more mvc." I'm open to ideas though, on the MVC-related nodequeue issue you posted.

merlinofchaos’s picture

merlinofchaos commented

Sorry, the nodequeue is fundamentally different from what flag does, to be honest. Yes, both modules mark nodes, but nodequeue gives them an order, it controls how many there are, and it provides a UI to make this pleasant for the administrator, while still providing a powerful API allowing you to go around the UI when your site's needs deem it necessary.

In addition, as flag has grown, it can now flag items that aren't just nodes, whereas currently nodequeue is sticking with nodes.

flag.module is necessarily very simple. This simplicity can be important, and can lead to better performance than nodequeue will in some situations. I wouldn't sacrifice that for anything.

Having written the original versions of both modules, I would never consider combining them.

julma’s picture

julma commented

Yes nodequeue is better.

Maybe it is good to have two modules for the same purpose at the beginning. It is challenging.

But after some times, it is better to have one generic solution.
We don't want several views, several CCK or several panel modules. It would be nice to have also one "queue" module.

Ok I will add some ideas in the other issue about MVC with nodequeue.

merlinofchaos’s picture

merlinofchaos commented

Yes nodequeue is better.

That's not my point. In fact, there are many purposes for which flag.module is better. Nodequeue is different.

These modules only do the same thing on the surface.

merlinofchaos’s picture

merlinofchaos commented

Also, maybe I should clarify my thoughts on performance.

If I've got a pure bookmarking application, which is one of the primary uses of flag, these bookmarks are unlikely to get recycled. Items are marked and over time they build up. Hundreds, maybe thousands of items might be marked.

The way nodequeue deals with ordering, handling the queue is a O(n) operation, which is to say that every item in the queue makes operations on it slower. Having thousands of items in a nodequeue makes the UI simply unworkable, and it also makes the code to handle renumbering when items are inserted very very slow. It's a very bad fit for some of the purposes that flag.module would be used for.

Such a bad fit, in fact, that I would probably have to go and write another flag.module if it didn't exist.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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