Return-Path: Delivered-To: apmail-ws-axis-c-dev-archive@www.apache.org Received: (qmail 18459 invoked from network); 6 May 2004 21:44:51 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 6 May 2004 21:44:51 -0000 Received: (qmail 23439 invoked by uid 500); 6 May 2004 21:44:40 -0000 Delivered-To: apmail-ws-axis-c-dev-archive@ws.apache.org Received: (qmail 23431 invoked by uid 500); 6 May 2004 21:44:40 -0000 Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: List-Id: "Apache AXIS C Developers List" Reply-To: "Apache AXIS C Developers List" Delivered-To: mailing list axis-c-dev@ws.apache.org Received: (qmail 23417 invoked from network); 6 May 2004 21:44:40 -0000 Received: from unknown (HELO EXCHANGEUS.edocs.com) (63.114.227.95) by daedalus.apache.org with SMTP; 6 May 2004 21:44:40 -0000 Received: by exchangeus.edocs.com with Internet Mail Service (5.5.2650.21) id ; Thu, 6 May 2004 17:43:55 -0400 Message-ID: <8A6229AB5BE35447A7A838D64C1792BB12C1B5A9@exchangeus.edocs.com> From: Lilantha Darshana To: 'Apache AXIS C Developers List' Cc: Damitha Kumarage , Aleksander Slominski Subject: RE: Transport Abstraction question Date: Thu, 6 May 2004 17:43:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Decoupling between transport and XML parsing need to be considered. There are two side of the coin when we think about performance, whether to sacrifice the design quality and go for a poor design to improve performance. or achieve better performance with a clean design? Introduce a Ring Buffer Manager in between the transport layer and XML payload reader/writer - to make it a producer/consumer model. Reading will block if the buffer does not have enough data for reading, this traps RingBufferManager to read data from transport and fill the buffer. Writing will synch data to the target. Transport layer will block until axis writes output to the RingBufferManager. For Xerces we can provide a InputSource, by using above model. function calls like releaseBuffer(..) need to be encapsulated in the RingBufferManager. then the interfacing between transport and axis is cleaner. regards -Lilantha -----Original Message----- From: Susantha Kumara [mailto:susantha@opensource.lk] Sent: Thursday, May 06, 2004 1:31 AM To: axis-c-dev Cc: Damitha Kumarage; Aleksander Slominski Subject: Transport Abstraction question Hi all, I am working on Transport layer and Parser layer abstraction and got following question, At the moment Axis assumes that the receiving part of the transport layer can behave in 2 ways. 1. Some transport layers allocate memory buffers / fills them with receiving data and gives to Axis.(see getBytes(..) function) Ex : When using Expat parser These transport layers want Axis to inform them when Axis has finished using the given memory buffer.(see releaseBuffer(..) function) 2. Some transport layers don't allocate memory buffers but will fill the given buffers (from Axis). Ex: When using Xerces parser. But generally its VERY difficult for a XML parser to use the buffers given by outside. Especially when the XML document is given in parts. In above 1st case too Expat internally copies all data passed to it into its own buffer. That buffer inside Expat grows finally to the size of the whole XML document. But if we get a buffer allocated inside Expat and pass it to the transport layer to be filled and given back that would be more efficient in terms of memory. In above 2nd case Xerces allocates a buffer of around 48KB and passes it to transport to be filled. So It seems that there is no point of supporting case 1 as long as there is no XML parser that is capable of efficiently parsing (without copying to its other memory buffer) memory buffers allocated outside of the parser. Those who have experience in writing an XML parsers will understand this problem better. So what about supporting only case 2 in the upcoming transport API ?. --- Susantha