RE: http_url_post and CGIDEV2

[Nick Townsend <Nick.Townsend@xxxxxxxxxxxxxxx>]

Scott,

Thanks for pointing out about freeing-up the memory allocated to the copy
of the HTML buffer when you've finished - I had meant to mention that but
I forgot.  I have to admit that we don't usually bother as most of the
xml messages that we generate (at the moment) aren't huge, and we tend to
use this technique in server jobs so we let the final memory allocation
get freed when they terminate.

Like you I'm not completely happy with CGIDEV2, but it works well enough
(for us) that it's hard to justify the time needed to write something to
replace it.

We chose to go the route of customising CGIDEV2 to get at the HTML buffer
rather than using the IFS option chiefly because of performance concerns.
Admittedly the decision was based more on gut feeling than any definite
evidence, but we have encountered performance problems with other
applications where IFS I-O seemed to be a bottleneck.

Regards,

Nick

___________________________________
Nick Townsend
Technical Leader
Endsleigh Insurance Services Limited
Telephone: +44 (0)1242 866866 ext. 6426

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: 01 April 2009 18:25
To: HTTPAPI and FTPAPI Projects
Subject: Re: http_url_post and CGIDEV2

Houghton, Steve wrote:
>     in the code.  Is there a way to use the CGIDEV2 updHtmlVar/wrtSection
>    procedures to create the XML buffer and instead of using AppHtmlToStmf
>    to write to the IFS, make gXml = to the HTML buffer?

CGIDEV2 has never provided a way to get a pointer to it's HTML buffer --
someone else asked about this at one time (Jon Paris, I think?) --
obviously, you can modify CGIDEV2 as Nick did -- if you do use Nick's
code, please make sure you call TS_free() to release the memory when
you're done.

The other way, of course, is to use CGIDEV2's routines to write to a
stream file (AppHtmlToStmf or WrtHtmlToStmf) and then call
http_url_post_stmf(). HTTPAPI does provide a rotuine called
http_tempfile() that will generate a unique temporary file name, you
could generate the temp file name, then call one of the xxxHtmlToStmf()
routines to write to the temp file, then call http_url_post_stmf() to
send it off...

There are pros and cons to both methods...

The stmf method is probably slower... though I don't know how much.  You
might not even notice it...  but will work with stock versions of CGIDEV2

The pointer method requires modifying CGIDEV2 (as Nick demonstrates) but
is probably faster.  You just have to remember to re-modify CGIDEV2 each
time you update it.  If you have multiple machines, or want to
distribute your code to customers, you need make sure that they all have
a modified version of CGIDEV2, which can be a real nightmare to support.
  But probably doesn't matter much if this is for one application on one
machine.

So... pros and cons to each method.

Personally I've been thinking quite often that I need to write my own
templating engine...   CGIDEV2's support isn't great, and there's stuff
about it that I don't like, and it'd be hard to change at this point. I
could write my own templating tool and add it to HTTPAPI, that'd make
things simpler...    but who knows if I'll ever get around to it?
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

Information contained in this email is intended for the use of the addressee only, and is confidential and may be the subject of legal professional privilege. Any dissemination, distribution, copying or use of this communication without prior permission of the addressee is strictly prohibited. If you have received this email in error please notify the Help Desk at Endsleigh on 01242 866866.
The contents of an attachment to this email may contain software viruses, which could damage your computer system. While Endsleigh has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage, which you sustain as a result of software viruses. You should carry out your own virus checks before opening the attachment.

http://www.endsleigh.co.uk
Endsleigh Insurance Services Limited is authorised and regulated by the Financial Services Authority
Company number: 856706
Registered in England at Shurdington Road, Cheltenham Spa, Gloucestershire GL51 4UE
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------