Hi Scott,
I did not benchmark the differences between parsing the XML stream directly
versus saving it to the IFS and parse it in a second step. However whenever
we had a performance problem it was because of IO operations most of the
time.
I like your idea of a http_url_post_mime() procedure. That was a great
improvement for HTTPAPI. Perhaps we can add that procedure in a second
step. Don't you think that the changes I made in HTTPXMLR4 were useful for
http_url_post_mime(), too? Feel free to have a look at the changes.
I assume that we need two versions of http_url_post_mime(). The first one
sends data from memory and the second one sends data from a stream file:
http_url_post_mime(url: data: length: ???)
http_url_post_stmf_mime(url: stmf: ???)
Internally both routines may call http_url_post_raw_mime().
I do not have any idea about the parameter list at '???'. On one hand we
had to pass the names of eXpat callback procedures and on the other hand we
had to specify a procedure to receive the mime attachments. How should we
receive the mime attachments? Should we forward the name of a temporary
file containing a single attachment or should we forward the data of the
attachment? We also had to forward the headers of the attachment, don't we?
For best performance it was great if we could forward the data of the
attachment at the time it is received without using a temporary file,
couldn't we? Do you think that we should forward a SOAP attachment directly
to the parser or to you think that the procedure receiving the attachments
should foward the XML stream to the parser?
Lot's of questions that your idea dropped into my brain.
Thomas.
Patch files:
(See attached file: HTTPAPI_v1.24beta1.ZIP)
ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 05.11.2008 19:44:06:
> Hi Thomas,
>
> I haven't benchmarked the differences between parsing the XML stream
> directly vs. saving it to the IFS and parsing it in a second step. Is
> there a significant performance difference?
>
> As for detecting the difference between SOAP vs. MIME, that should be
> extraordinarily simple. Just call http_header() to get the
> content-type. For MIME (Soap with attachments) it should have a
> content-type of multipart/related (if you want to make it more generic,
> just search for "multipart").
>
> Perhaps we should have an http_url_post_mime()... if the data isn't
> multipart, that routine would work very similarly to
> http_url_post_raw2(). But if the data is multipart, it breaks things up
> into parts, and sends those to callbacks, as if you called
> http_url_post_raw2() separately for each "part" of the "multipart"
message.
>
> Thomas Raddatz wrote:
> > Hi Scott,
> >
> > What you suggested is almost the same of what I have in mind. The main
> > difference is that I want to
> > to avoid writing an IFS file in case that is is a 'simple' SOAP message
> > with no attachments. In that case I want to forward the HTTP response
> > stream directly to the parser. That means that the receiving callback
> > procedure have to recognize the incoming HTTP stream and the forward it
> > either to the parser or to an IFS file. Is that a reasonable idea?
> >
> > Regards,
> >
> > Thomas.
> >
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the
intended recipient only. Access, disclosure, copying, distribution, or
reliance on any of it by anyone else is prohibited and may be a criminal
offence. Please delete if obtained in error and email confirmation to the sender.Attachment:
HTTPAPI_v1.24beta1.ZIP
Description: Zip archive
----------------------------------------------------------------------- This is the FTPAPI mailing list. To unsubscribe, please go to: http://www.scottklement.com/mailman/listinfo/ftpapi -----------------------------------------------------------------------