Getting money for Gnucash development [was Re: Newbie migration issues]

[Neil Williams]

On Saturday 05 February 2005 2:46 pm, Derek Atkins wrote:
> I think the source code layout isn't as consise as it could be, but
> each individual source file is fairly well modularlized.

The Doxygen output is particularly helpful.

I've only recently started working within GnuCash and particularly QOF. I find 
QOF very easy to learn, very simple to use and, most important of all, easy 
to port.

I've almost completed a wrapper for pilot-link that uses QOF to provide:
1. An XML backend
2. A SQL interface
3. A query mechanism that is independent of the existing conduits.

The power of this cannot be underestimated. Existing conduits need to be 
laboriously re-coded to handle changes in the databases or query structures. 
QOF removes all that and just requires an updated description of the database 
in QofObject and QofClass. By providing command line and file access to the 
SQL-like queries supported by QOF, anyone can obtain their Palm data in any 
format whenever they like. It will transform how Palm data can be used by 
desktop applications and handhelds.

> Seriously, the more you look at the code the easier it is to
> understand. 

I second that. I spent ages getting to know the codebase and Derek can testify 
to some of my dafter ideas. QOF I understood quickly, the gnc_ stuff took a 
lot longer - and is still ongoing.

> > QOF is a reinvention of querying capability used only by gnucash and
> > gnucash authors. It's an unnecessary abstraction layer

Untrue. QOF is a useful query layer that provides self-describing objects. The 
most important part is the simplest, in theory: by having only one QofEntity, 
you can find the entire QofCollection of those entities in the current 
QofBook. Starting with one object, you can iterate over every other object of 
the same type. That alone is very powerful.

> > that makes 
> > gnucash more difficult to write code for and is a hurdle to learning.

??? QOF was the easiest part of the entire codebase for me to learn!

Personally, I don't think you understand GnuCash and if you take the time to 
work with QOF - maybe read the doxygen output and my own documentation on 
qof_book_merge - you may change your opinion. QOF is easy.

> > No 
> > matter how good it might be technically, I will never believe it to be
> > superior both to SQL and to all of the RDF and XML query capabilities

It is superior because it is smaller and more efficient. RDF and XPath are 
overkill and laborious. QOF is simple, quick and flexible.

> > developed over the last few years.

As Derek says, GnuCash began before all those.

> QOF as it stands now is just a refactoring of the query engine gnucash
> has been using for almost a decade.  Nobody else is using it yet
> because it was only recently refactored.  It takes time for people to
> see and start using a "new" package.

I've got it working as a framework around pilot-link and I'm hoping to get QOF 
onto portable devices as a data interchange and abstraction layer between 
applications on smaller devices. QOF is ideally suited to being used as the 
data interchange layer from one application to another. Application objects 
describe themselves to QOF, QOF writes generic streams that the next 
application can map and use as native. The key is that each application can 
change how they handle their own data without breaking handling in another 
application. 

Remember, these are applications (more like applets really) on small devices 
like a handheld that know nothing of MySQL, Postgres, RDF or even XML 
natively. All they have are C structs that contain their data objects. A 
simple wrapper struct and a set of get and set routines is all that is needed 
to link those into QOF. Other applications can then query the entire data set 
of a different application, retrieve objects that have been mapped to the 
native C objects in the recipient application and import the data.

This can happen in real-time with data streams. Imagine the Contacts applet on 
a handheld being able to cross-reference your customers with your calendar 
events, ToDo list and Expenses - in real-time!!

THAT is what QOF can do on a handheld that no other layer can achieve.

> > C combined with an out of date GLIB and GTK is not easy to work with.

Ahem, then why not help with the G2 port instead of criticising??
:-)

I could have just sat at home whingeing about a lack of an invoice creation 
mechanism in GnuCash, I could have read the early replies to my ideas on the 
devel list and given up or sulked. I could have wasted years of my time 
trying to invent NewGnuCash on my own. That is all pointless - development 
needs cooperation and you need to JOIN rather than compete, unless you are 
certain that a forked project would attract enough developers.

> > It 
> > requires a whole lot of typing to do anything useful. 

GUI tools are over-egged - code happens at the keyboard, not the mouse.


-- 

Neil Williams
=============
http://www.dcglug.org.uk/
http://www.nosoftwarepatents.com/
http://sourceforge.net/projects/isbnsearch/
http://www.neil.williamsleesmill.me.uk/
http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-user/attachments/20050205/08d0c63e/attachment.bin