Re: Latest changes...OFX partner server

Is there some way to disable the QT requirement?  I don't use QT at all
and was able to use this library with gnucash until this change.

Thanks
CuZnDragon
Robin Cook

On Tue, 2006-02-21 at 16:49 -0800, Ace Jones wrote:
> 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
> _______________________________________________
> Libofx-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/libofx-devel
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (GNU/Linux)

iQIVAwUARATpd0R0KI3mhyXmAQI4qBAAo3w13AjRhtxA1SfKCbXb/ly2AA21z8eE
1VmJgX2E3xcI2lSD85N4MSJssCDEtdVqMwkhkAqWVAUxEfxisEPfM+Ag0Eb8e6Wi
UQ2t9KbNAsLSH9AmI3o0+9J/GZ1ZIRQqUZLg/TSQFsHWX0e7nfR3unZycKlsJks8
s5PDfeODFIZYHOLQv3DBPMm87v/YQso49Bx3ipZY6Lm46iTXWXyKypN/aB4W3Fyn
vJDNN5KlCFX6jZH9FvK+kDYzar1wKJ23v9JPg5ZBODX7s5Tfg8Vcqz04Uv9chNP6
LAAeKV9qSj4u0MG96uPkz0enyFCPom7LiJG80yeyRxWRca0ylyLWc6vREmM6s72G
UaRb/5QpE8ZJhZNF67MKB9YZHlx4RUXDGBdM2OsVuWMtaXPO/y9ouFkQ62waHiEd
TfucVGcqqk+F/C7RMCad5Q3jXnPLbHPCyqv1ecYq+EDdj5u1Ufs20CI2AIVg8hxR
rYaFCXMCzXB9yqYAI5G0Km6+8jVJdiM2Jn0tGUlkiuouzBpwGMvH9lnCXoKL2Srz
1bxfTWhzCWTv2dc+x3aj5B5Qjdkuq05haXlFKCsNFgsDsyAHIg8KFX/K9iRiPYfB
5D/oh77eeQCx2pOMcWDRXVG9PAXiAMgCMGHbAtw5HlzVVdEsocYvKa88g5zYxTak
37XHey1Ep08=
=GOee
-----END PGP SIGNATURE-----