[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: HTTP API question



LPI as we use it would be - Local Pprogram Interface.

I guess I will go with saving it to a IFS file.  I'm not saying it would
be hard to put the response in a file and read it.  It just seems to be
a unnecessary step in our situation - for performance reasons.  Realize
the sole reason we are taking this RPG HTTP post approach is for
performance reasons.  We want to eliminate the RPG to Java web-server
approach for performance reasons.

I'm assuming all of the response will be in the IFS file before
processing is returned to my program regardless of network speed or
webserver performance.  Therefore, if in our situation, we are sure that
our memory will be enough for the entire response why have the interim
step to a file?

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott
Klement
Sent: Tuesday, September 18, 2007 2:09 PM
To: HTTPAPI and FTPAPI Projects
Subject: Re: HTTP API question

Hello,

Can someone clarify what is meant by "LPI" in that message?  (I assume
it's not "lines per inch"!)  Either I'm not familiar with the term, or
I'm drawing a blank.

HTTPAPI can return the response from the servlet in 3 ways:

1) the "raw" procedures return the response via a callback.

2) The "normal" procedures return the response by saving it to a file in
the IFS.

3) The "xml" procedures run the response through an XML parser, and send
you the XML data via a callback.

If your goal is to receive the data into memory, then you can do that by
using the "raw" procedures.  Just write a callback that saves the data
in the format you want it.  The callbacks get the data immediately as
it's received from the web server, and the size of the data is random --
it depends on how busy the web server is, how fast your machine is, how
fast the network is, etc.  So you'll want to accumulate it in the
callback routine until the download is finished and you have it all.

One easy way to accumulate it is just to append it to an auto-expanding
user space.  Another way (which isn't difficult, either, IMHO) is to use
dynamic memory allocation, or even teraspace allocation.  It's just not
that hard!

When the HTTP download is done, you can take that data and break it into
chunks and pass it to your other program -- again, you'd write the code
to do this, but (for me anyway) this would take about 10 minutes to
write, so I don't see the big deal.

Alternately, save it to a stream file, and read the stream file in
chunks... very easy to do.  I wonder why you balk at that?



Wes Breinich wrote:
>    The HTTP API may very helpful to us.  I'm not very knowledgeable
about
>    HTTP.  In reading through the documentation and source code I come
to
>    this conclusion.  You get responses from the HTTP posts via output
to
>    a file -or- through a parsing mechanism.
> 
>    We have a reasonably sophisticated HTTP servlet
>    application (SystemLink) written in Java that processes database
and
>    application transactions.  It has no user interface.  It accepts
XML
>    headless tranasactions and hands back any necessary feedback
through a
>    response.  This servlet can basically process any transaction
>    available in our java GUI interfaces.
> 
>    I've been given the assignment of developing a RPG local program
>    interface into the servlet.  We already have a RPG/java LPI.  An
RPG
>    process starts up java and calls classes to send requests/receive
>    responses to/from the servlet.  We now want a RPG POST LPI to do
the
>    same thing without having to startup java (performance).
> 
>    The current RPG/Java LPI receives the XML response as one chunk of
>    memory.  The servlet is sophisticated and has request methods to be
>    instructed to return data in manageable XML memory chunks.  We'd
like
>    the POST LPI to have the same structure.  The LPI function has no
>    reason to do parsing.  It simply wants to hand back POST responses
in
>    memory chunks to the caller.  I'd like to hand the POST API a
pointer
>    to memory for the response.  Is there a current way to do that -or-
>    could anyone advise me if this would be feasible for us to make a
>    change in this area?
> 
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------