Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 44956 invoked by uid 500); 4 Feb 2002 05:59:12 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Delivered-To: moderator for cocoon-dev@xml.apache.org Received: (qmail 18204 invoked from network); 3 Feb 2002 19:05:18 -0000 Date: Sun, 3 Feb 2002 20:05:21 +0100 Message-Id: <200202031905.g13J5L804812@codeconsult.dsvr.co.uk> To: Subject: RE: [RT] Cocoon as OS In-Reply-To: <60F6EF824F0C284481CEF5F49D2F540303172F@centrum.digidemic.com> References: <60F6EF824F0C284481CEF5F49D2F540303172F@centrum.digidemic.com> X-Mailer: JAWmail 0.7.11 X-Originating-IP: 212.147.6.45 From: Bertrand Delacretaz X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On 02.02.2002 17:14:56, Brian Topping wrote: >. . . >Methinks JMS is too slow for this as a generalized transport. >. . . It all depends on how fast/slow the back-end processes are. If we're speaking of a database query + XSLT pipelines on the back-end, the JMS exchange can be just a small part of total request processing time. I wouldn't use JMS as a "generalized" transport though, but having an option to plug it in for the most complex/big/slow systems is certainly an plus. >. . . > It *does* seem applicable in a >workflow management scenario though, putting a document "on the bus" for >different sinks to process would work well, because the performance >expectation on CMS use cases aren't usually near that of OLTP/web >browsing. >. . . Agreed, having multiple JMS queues/buses in a CMS setting is certainly a good solution. - Bertrand --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org