Re: Latest changes...OFX partner server

Ace Jones <[email protected]> Tue, 21 Feb 2006 16:49:01 -0800
Newsgroups gmane.comp.finance.libofx.devel
Message-ID <[email protected]>
Ah, yeah, that's a good idea.  I would likely want to use this same
context for posting the request files to the bank server too.  The same
members would be needed.  So it would really become more of a "transport
context."

I suppose I could also create a context with callbacks for passing the 
partner data back.  The problem there is I deal
in vector<string>'s all over the place, which is a pain to duplicate
in C.  Or at least, so I seem to remember :-)  It's been over a decade
since I wrote any C code.

</Ace>

On Tue, Feb 21, 2006 at 09:28:11PM +0100, Martin Preuss wrote:
> Hi,
> 
> On Tuesday 21 February 2006 18:34, Ace Jones wrote:
> [...]
> > I am starting to lean toward the idea of libofx handling the transport
> > for online banking internally instead of leaving it to the caller.  As I
> > get further with online banking, it will be something to consider.
> [...]
> 
> I would propose another way. I studied your implementation in KMyMoney, and as 
> I see it the HTTP-transfer can be very easily encapsulated: In your code you 
> call a function which sends a HTTP post request.
> 
> I think the best would be to define a OfxPartnerContext (see above) which 
> includes a callback.
> 
> We could let it point initially to a function which sends a request using 
> libcurl internally, but the application would have the possibility to do th 
> transfer itself.
> 
> There are two important reasons: 
> 
> 1) the two main users are KMyMoney (KDE) and AqBanking.
> KMYMoney uses KDE/QT which have nice functions for HTTP requests which 
> integrate seemlessly into the KDE framework.
> 
> AqBanking uses its own transfer management (mainly because we want to avoid 
> GUI freezes without having to deal with multithreading).
> 
> So it would be very nice if the callers would keep control over the transfers.
> 
> 2) the second reason is that the application needs to be in control over where 
> the index files etc are to be stored. This could also be stored within the 
> OfxPartnerContext.
> 
> What I suggest is something along the line of the following:
> 
> /** function prototype */
> typedef int (*OFX_PARTNER_POST_FN)(OfxPartnerContext *ctx,
>   const char *url, const char postBody, const char *fileName);
> 
> struct OfxPartnerContext {
>   char *folder; /* donwload folder for index file etc */
>   OFX_PARTNER_POST_FN postFn;
> };
> 
> 
> We could even provide a default postFn which calls curl or whatever you like, 
> but still the application would have full control over:
> - where files are stored
> - how they are retrieved from the partner server.
> 
> 
> Kind regards
> Martin Preuss



-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642