Provide a reliable queue interface

Like the approach and would help move #89181: Use queue API for node and comment, user, node multiple deletes forward (if we decide to go with the Queue implementation).

Only had time for a quick review, sorry:

+++ modules/system/system.queue.inc	2010-04-29 14:14:53 +0000
@@ -33,18 +34,22 @@
+ * insignificant next to power of the queue binge able to keep up with writes.

...the queue being...

+++ modules/system/system.queue.inc	2010-04-29 14:14:53 +0000
@@ -167,9 +180,19 @@ interface DrupalQueueInterface {
+ * Classes impleenting this interface preserve the order of messages and

Classes implementing ...

edit: wrong link.

Powered by Dreditor.

This would be a good change. update.module definitely uses the Queue API in a way that would be better using the "strict" interface. Sometimes you need different queue semantics, and there's no way for the API to know that -- only the "customer" of the API can decide what semantics they need and what tradeoffs they're willing to make. Given that update.module wants a strict queue, we want strict for #89181: Use queue API for node and comment, user, node multiple deletes, and yet we want non-strict for aggregator feeds, etc, it'd be good to make this interface change directly to the Queue API itself in D7 core -- we've already got "customers" in core that want both interfaces...

However, this at least needs work for:

A) The typos mr.baileys points out in #4.

B) It seems like the queue_default_strict_class variable should to be documented somewhere in the PHPDoc, probably the block for DrupalQueueStrictInterface. I'm also wondering about adding a @see to the block for DrupalQueueInterface that points to DrupalQueueStrictInterface, since otherwise it's not obvious how developers will know they have a choice in what kind of queue semantics they want to use.

C) I'm a bit concerned about calling this parameter and interface "Strict". I'm not sure that's the most self-documenting name for it, but I don't have a better alternative right now...

This is why we should always have a definition hook for swappable components like this, even if it doesn't seem like we need it immediately; that's where this sort of metadata belongs. Not implementing it that way originally was a mistake. Unfortunately, I doubt we can fix that at this stage. Let this be an object lesson for later. (Pun very much intended. :-) )

With that said, using an interface will work and is probably the best we can do even if yet-another-variable and an empty interface is kind of a hack. I agree that this is an important designation to have. We can switch it to a definition hook and get rid of the flagging interface in Drupal 8.

I'd probably put all of the documentation about strict mode in the DrupalQueueInterface doblock, so that it's all in one place. Unless we have a @group definition for it already.

As for "strict", maybe "ordered"? True insists on getting back an order-guaranteed queue, False doesn't care.

Patch prevents installation with fatal errors:

Fatal error: Can't inherit abstract function DrupalQueueInterface::numberOfItems() (previously declared abstract in DrupalQueueStrictInterface) in \modules\system\system.queue.inc on line 203.

Srry to interupt but the doxygen police is back in town.
Chx already knows what to adjust ;).

Ow btw the *new* class doxygen style proposal (for classes, interfaces, ...) is almost accepted.
So if you wonna be übercool you can read that proposal to ;)
==> http://drupal.org/node/718596

I'm tempted by Crell's proposal in #6 to use "ordered" instead of "strict" for the interface and get() argument. In some ways, it's more self-documenting, since "strict" could mean just about anything. However, "ordered" doesn't necessarily have to imply "we execute everything in the queue". There are certainly systems that run in order but don't guarantee that nothing is ever dropped. Furthermore, if you know anything about queues and you have to choose between "ordered" vs. "unordered", you're going to think "FIFO" vs. "set". You'd probably assume that the only consequence of selecting a "non-ordered" queue is that your tasks could execute in any order. You wouldn't necessarily assume that "unordered" really means "best effort, we might loose some of your work". So, I think "ordered" would do more harm to developer expectations than it would help clarify WTF "strict" means.

So, we still don't have a good name for this. :( You'd think after dealing with job schedulers and queue systems for over a decade for my previous day job, I'd have a ton of potential terms to use for this, but sadly I'm mostly drawing a blank. ;) "(Non)deterministic" comes to mind, but it's not great, either. Unless we find a better name, I'm prepared to support this as "strict", but I'm not RTBC'ing yet.

Well apparently he doesn't....

could you change get to gets (I know it was there before the patch)

   /**
    * Get a queue object for a given name.
    *

And put a newline after the @param block

Yeah, that's pretty good. I'd certainly prefer "guaranteed" to "strict", even if it is a few more keystrokes to type. It's still unclear what's being guaranteed, but I don't think we'll get the perfect one word that covers all the semantics we're offering. If nothing better comes along, I'd be okay with that...

Thanks,
-Derek

What about "reliable"?

This seems analogous to UDP vs. TCP.

TCP is often described as "reliable".

It's funny, I was going to mention UDP in my comment #14. ;) I like "reliable" even more than "guaranteed", and therefore definitely much more than "strict". I don't want this to turn into a monster bikeshed (bikethread?) ;) so let's just go with "reliable". It's certainly the best option we have so far, and while self-documenting names are important, it's even more important that we get this change in ASAP. ;)

So, needs work for s/strict/reliable/ to the patch in #12. After that, and fixing the PHPDoc conventions from #15, this is RTBC.

Thanks, everyone!

Just to be annoying, I will point out that if it is not a guaranteed ordered FIFO data structure then it's not really a queue. It's technically a "sac" or "bag" depending on if it's unique or not. Queues by definition are FIFO data structures.

Yes, yes, we know. ;) Hence, an "Unreliable" queue.

Besides, "queue" is used to describe lots of things that aren't strictly FIFO, e.g. the "issue queue".

#823500: $is_https should always reflect $_SEVER['HTTPS'] even if $base_url is http seems to have been merged in the latest patch.

Right, #23 isn't RTBC at all. ;)

Yay for "reliable".

Not to split hairs, but I wonder if "DrupalQueueReliableInterface" or "DrupalReliableQueueInterface" makes more sense. It's an interface for a reliable queue, not a reliable interface for a queue... ;)

@chx: you've done it again. This issue is just for the reliable queue interface and doc changes. Please don't set this to RTBC yourself. I promise we'll RTBC quickly once you post the right patch. ;)

Here's the patch just for DrupalQueueReliableInterface. Still not sure if I like that or would prefer "DrupalReliableQueueInterface", but I don't think it's worth holding this up any longer over...

Return => Returns

(I wish I just could edit that in your patch without making a new one...)

Fixes #30... whatever. Someone please RTBC. ;)

Ok chx missed that one... I'm ok with that.
I can't rtbc.

seems like everyone likes this patch but is too chickenshit to rtbc. hah. rtbc it is.

Looks clean and works. Committed to CVS HEAD. Thanks.

Thanks for the commit. FYI: #827150: Use DrupalQueueReliableInterface for update manager queue operations if anyone's interested. Also, better title for people who don't know WTF "ACID" means in this context... ;)