[Gnutaxes-dev] Re: GnuTaxes...

[Jim P. <jph...@er...>]

Below is a reply from myself to Pehr Anderson who had some questions
regarding the portability of gnuTaxes.  I thought my reply did a pretty
good job of describing the relationships between the processing engine and
the user interface.  So here it is in case anyone else was wondering.

- Jim

Jim Phillips wrote:

> pehr anderson wrote:
>
> > Dear Jim,
> >
> > GnuTaxes is a great idea! I love it.
> > You mention Gnome, KDE & Motif front ends.
> > I strongly encourage you to clearly define
> > an implementation path on your website.
> > The best open source projects use the
> > benevolant dictator model. You must be
> > willing to dictate!
> >
> > >From what I know of the history of the Gnucash project
> > there were major issues resulting from confusion
> > over which development tools were and were not allowed.
> > Ideally a project has as few dependencies as possible
> > and follows a single path to completion.
> >
> > Once a vibrant and robust development community
> > is built up, then a project can start flushing out
> > alternative inerfaces and such.
> >
> > To meet your end-goals of cross-platform sufficiency,
> > you really only have two options, Java or Python.
> > Python has a built in gui called tkinter based which
> > uses TK/TCL. Python is definitely the path I recommend.
> >
> > C is portable but compilation environments are different
> > once you get outside of unix.  Python works
> > transparently on Windows, Linux, Unix, & MAC.
> >
> >         -pehr
> >
> > Good luck! and thanks for adding to the pool.
>
> Thanks for your advice, but I _sort_ of disagree with you.  Several of
> your comments I do agree with, but as far as the platform independence
> mechanisms, I'm pretty sure we'll be able to do it the way I'm currently
> envisioning.  Here's what I'm thinking (and I'll point out another
> project that does pretty much the same thing - www.jabber.org).
>
> The bulk of the programming logic will have no knowledge of a user
> interface.  This will be the part that actually parses the forms,
> computes the values, merges the data with the PDF files, and transmits
> the data to the eFile system or whatever other electronic clearing
> house.  All of this functionality will be coded in standard ANSI C in a
> manor that is as easily portable as possible.
>
> The other part of the application is the interview system.  This is
> where the platform dependence and need for multiple clients show
> themselves.  I actually _want_ clients written for a specific platform
> because I personally hate having to use applications that are designed
> to be cross-platform compliant.  I prefer to use applications which take
> full advantage of the features my environment offers.  And you just
> can't write a good cross-platform application that still takes full
> advantage of the specific features of a particular platform.  But at the
> same time, I do want to have some control over the creation of the
> clients.  So the gnuTaxes library I spoke about before will expose a
> very specific API for handling the interview.  The only thing that the
> client should be doing is displaying dialogs and gathering user input.
> So the API will have essentially two functions.  read_dialog (); and
> write_data (); (or something like that).  The read_dialog function will
> be the clients way of asking the application for the next dialog to
> display (it will be returned as an XML document structured very much
> like the <dialog></dialog> block already defined.  The client will then
> parse and display that individual dialog and wait for user input.  Once
> the user inputs data and clicks a button, the client will call
> write_data (); and send the data back to the application in a second XML
> document (which I haven't yet defined).  That's it.  That's all there is
> to the GUI.  Basically just something that knows how to parse a specific
> XML document and display that as a page of a wizard, and something that
> can create an XML document from a few input fields.  By doing this it
> should be extremely easy for people to write a large number of different
> client GUIs that take advantage of whatever platform their written to.
>
> Somewhere down the road, I might want to expose some more advanced
> options to the clients, such as the ability to display the tax form
> graphically as it's being filled in, or '']he ability for the user to
> hop around inside the interview without having to use the "Back"
> button.  But that's a long way off.
>
> As far as any portability issues between *nix and Win32, my way of
> thinking is that Win32 already has gobs of tax programs, so I'm not too
> concerned, but we'll probably use something like Cygwin to port it
> anyway and then someone can write a GUI to take advantage of the
> features that Win32 offers.  As for other systems such as BeOS or MacOS,
> or other non-*nix OS's, well, again the primary target is *nix, but
> we're going to try to write our code with portability in mind.  For
> really really thin clients, we'll provide them a web interface using a
> PHP3 module.
>
> As far as using Java or Python?  Well, I'm not a big fan of interpreted
> languages.  I still am yet to be convinced that Java will have a place
> in the client niche (servers yes, but they've got the horsepower to
> handle java).  I don't know a whole lot about Python personally, but if
> it is indeed an interpreted language, the the same logic applies - that
> just requires too much horsepower.  I'd rather have highly tuned
> compiled applications which take advantage of the users environment.
> gnuTaxes will use some run-time scripting code already for computing
> values within the forms and for running custom actions in the interview,
> but I'm still undecided on which scripting language to specify -
> probably will wind up being either perl or creating our own (I've used
> javascript so far in my samples, because I know javascript from all the
> web development I've done in the past).
>
> Again, thanks for your input and hopefully, this has cleared up some
> questions you had.
>
>    - Jim