Re: Latest changes...OFX partner server

Did it fail to build without Qt??  That's a mistake on my part if so.

</Ace>

On Tue, 2006-02-28 at 16:23, Robin Cook wrote:
> 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
> > 
-- 
GPG Public Key: http://keyserver.net:11371/search?q=0xF540E55B
Fingerprint: 3CA8 1A24 B52F 4FCA C22D  0E2F 0AF0 4EE1 F540 E55B

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

iD8DBQBEBRXuCvBO4fVA5VsRAjrjAJwLh68Pnbr5p1yNKsdSAw1TPb/3mgCfR2gF
pUjGxP+BSsWsvZttyxaaKng=
=k8an
-----END PGP SIGNATURE-----