LibOFX development

On July 14, 2003 08:04 am, you wrote:
> C++ is not a problem for me; it is actually my mother tongue, so to speak.
> The reason I'd like a Java OFX implementation is because I want my Java
> stock tracking program to read my broker statements (Money or Quicken
> format, but I think it is OFX)) into a table of stock trades.  However, if
> I can find an ODBC or some other standard, open source C++ database
> library, I can always implement the transaction import in C++.  Know of any
> good C++ database libraries similar to Perl DBI?

I don't know any specific ones, you can take a look here, there is a list:  
http://debianlinux.net/databases.html

> I would like to join your project.  What would you like me to do and where
> do I start?

Hey, I just noticed that you are in Montreal, could be convenient!  Well the 
first step would be for you to subscribe to libofx-devel and read the 
archives, we should also move this conversation there, so others can chip in.  
Don't worry, the archives are not very long.  Much of the discussion on the 
early development of libofx and on Direct Connect support took place on 
gnucash-devel, but I don't expect you to read back such a high volume list :)

My current pet project is export support (ofx, qif, csv).  The current #1 user 
asked feature is DirectConnect.  Both require my number one urgent but boring 
project, the API redesign.  So the first thing I would need from you is a 
good dose of constructive criticism.  The original API was designed to make 
it excessively simple to understand and use the API, and followed the OpenSP 
API paradigm (that didn't turn out to be such a good idea).  In a way it 
succeeded, but much has to change for libofx to transition to a more general 
financial IO library.  Still, take a look at the current API (use the doxygen 
docs) and give me some feedback.  Here is a very basic list of currently 
planed API changes.

-Convert to a proper callback registration system to get rid static (compile 
time) callbacks.
-Probably get rid of most current callbacks in favor of a querying, iterator 
style interface.   Are the current ofx_proc_nameofstructure callbacks still 
usefull?  The have the huge inconvenient that they force the app to get his 
data in a specific order.  You can't currently ask for libofx "Give me the 
list of all accounts in the file" (and only that).
-Access functions to fill the data structures to allow export support.  This 
would be extended for direct connect (you would "export" to your bank a list 
of account to get balance, a transaction, etc.)
-I feel that the data structures are still mostly appropriate, but I'll take a 
long hard look at some elements.  Any field that can be eliminated of 
combined into one thru calculation by the library should be eliminated in 
order for the API to remain simple to grasp.  The meaning of any field should 
be clear to anyone who has a fairly goot accounting knowledge.

Your plans of writing data to a database would be just one more form of 
export, very similar to CSV.

Enjoy the good weather while it lasts,
-- 
Benoit Grégoire
http://step.polymtl.ca/~bock/



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1