-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi David,
David Reiser schrieb: > The more obvious problem with the null bankID institutions is that you > can't use the "Select the Bank for this User" dialog in aqbanking setup > to get the necessary connection data for the affected OFX institutions. well, that particular dialog probably needs to be fixed. It sounds as if there is some segfault if no bankid was entered -- maybe you can collect and report a back trace? But the real problem is somewhere else: > How big is the performance penalty for using bankID+bankName as the > internal aqbanking index key for the bank data? I'd really like to see > it be possible to have a null bankID because Vanguard refuses > connections if it gets any incorrect data in the ofx connect request. I understand why you would like to have that. However, this is where it hits the limits of a protocol-abstraction layer like aqbanking: For the first important protocol (HBCI), using "bankID+bankName" as an index key is plain wrong! Instead, HBCI explicitly specifies bankID (well, plus country code) and *only* this as index key for a bank. If we add the bankName, we will run into all kinds of trouble because the user might enter the bankName in whatever different way it ever occurs to him. So for HBCI, one *must* use only the bankID as the index key -- everything else will fail miserably. This is the explanation why the aqbanking protocol-abstraction still assumes the bankID as unique index key. If I understand you correctly, then in OFX we should not rely on this assumption anymore. Do the OFX specifications actually define a clear index key of the bank? (I have never worked with the OFX specs; I only know the HBCI ones.) I find it hard to believe the specs don't define something like this. > For a while I thought about the possibility of generating an ID for OFX > institutions that lacked them. But that gets ugly very fast: neither > aux1 nor aux1+aux2 is unique in the current data set. aux1+bankName > might be, but that's still ugly. In any case we need some unique index key throughout the aqbanking library, and because of the historical HBCI background, this happens to be the bankID (plus country code). If OFX requires something else as identification, then we have two choices: 1. Change the unique index key of the banks in aqbanking, and make the bankID field optional as seems to be appropriate for OFX (but not for HBCI, as explained above) 2. Change the interpretation of the bankID field in the OFX backend, but still use it as the unique index key for aqbanking. In other words, the bankId should not be transmitted to the OFX server but still be used inside aqbanking. Clearly #2 is the much easier solution here... wait a sec: If you look into src\plugins\backends\aqofxconnect\plugin\context.c and search for "BankCode", you will encounter this comment: /* only copy bank id if it is a number (-> routing number) * otherwise it serves only identification purposes for this backend * and doesn't represent a routing number */ Can you try to enter a bankId whose first character is a letter instead of a digit? :-) Regards, Christian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQCVAwUBRGQ7i2XAi+BfhivFAQIZnwQAiSMlrOgGAJwO/Vz8RIZn9Canz1LPXS5d vJEBfIx42cCYcgExzsSjT+Jk8MBxilFIooRW+pUxHHO9akaiZ9npqH1t1vdRcZ8Z oufKCX9zIaIkefN96EWVBSqGlUCBFhyGhZPZODMPVvuVhTb7vHuBl2e+XZ8nKoca aKSqrX2qXVo= =HMzk -----END PGP SIGNATURE----- ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Aqbanking-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/aqbanking-devel
