On Mon, 2007-01-22 at 21:27 +0000, Colin Crist wrote: > Hi Alan, > > I've seen other replies to this but I had this in draft so will take it mail > by mail.. > > The scenario you describe is different to my requirement - at least if I > read you correctly. [snip: argues that replay is a property of a Queue, not an Exchange. > Please correct me if I am missing any AMQP behavour as I'm only causally > aware of the spec from reading the docs and not working with it at this > point and I wont "get it" until I work with it closer.
The main reason I suggested a ReplayExchange is because custom exchanges are a recognized extension point in AMQP already, but I agree replay seems like a job for a queue. Queues are the storage agents in AMQP, the role of an Exchange is selection or routing. Clearly replay is all about storage. However we can't extend the behavior of a Queue without changing the protocol. That raises an interesting question: should AMQP support (custom) Queue types? Is it better to add replay (and probably other functionality) into a single swiss-army-Queue or to create a selection of Queue types (e.g. ReplayableQueue) that provide different functionality. Both approaches have pros & cons: the swiss-army-queue risks becoming over complex and penalizing simple users with undesired overhead from complex use cases. On the other hand multiple queue types suffer from inability to combine features provided by different queue types in a single queue? Cheers, Alan.
