axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Transport Abstraction question
Date Thu, 06 May 2004 07:03:17 GMT
Hi Susantha,

> 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.

Yes true, that expat copies the externally given buffers. But it can parse
as it receive buffers. it does not wait for the whole xml document to be
copied into its buffer. isn't it?

 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 ?.

That's a good.


View raw message