Scripting API

[Hendrik Boom]

On Sat, 12 Nov 2011 11:35:46 -0500, Nicolae Crisan wrote:

> I am 100% on-board this score. Again, finding the "boots on the ground"
> to do this is another matter altogether.

The existing Python scripting API would be a good place to start.  Maybe, 
all told, it's all we really need, except users who are obsessive about 
their language preferences.  If I were to try using Python and still felt 
I needed something more, I'd be tempted to volunteer for this.

Wasn't there an attempt to devise a common run-time system for dynamic 
languages some time ago?  If so, could that provide some scripting-
language independence?  This is far-off stuff, not really a gnucash 
issue, though.

> An accessible and well documented API is definitely a worth while
> venture in my opinion. API's have the effect of not only opening up
> other possibilities to the programs reach, but it generally has the
> effect of cleaning up other parts of the application that have not been
> so heavily developed or carefully attended to.

Yes.  Any formal review of a large code body usually finds places where 
it can be improved.
 
> Question, would this API change affect the portable nature of GnuCash or
> would it have absolutely no effect whatsoever? I'm used to working with
> languages and libraries that are provided everywhere I'm programming, so
> I'm not used to the "portable" aspect of programming. Most of my work is
> heavily based on server-side scripting (PHP, mainly) as well as local
> client scripting (JS, CSS, HTML, etc.).

Having the API by itself should have no effect on the portability of 
gnucash.  It would be just more code written in the same language as the 
rest of gnucash.    But *use* of the API as a shared library would be 
possible only on systems that have shared libraries.  And the semantics 
of sharing may differ substantially between operating systems.  I seem to 
remember that Windows shared libraries share writable data, whereas Linux 
ones don't.  Can anyone confirm this?

Where things could be really nonportable is in the scripting languages 
that might be implemented (by us or others) on top of the API.  There are 
probably lots of nonportable scripting languages.

> 
> In regards to your comment on creating some sort of front-end web-based
> architecture ... I have some reservations about this feature set. While
> I completely agree that would enhance and extend the reach of GNC, I
> would recommend that by default such a feature set be DISABLED. I know
> we're talking about stuff way in the future here, ,but just thought I'd
> point that out.

I wouldn't want gnucash to provide a front-end web-based architecture at 
all.  That's strictly for people who want to put financial information on 
the web.  Let them do the web programming to suit their aesthetic, 
practical, and security needs as part of their website implementation. 
All that the API would do is give them the hooks they need.

If I did anything like this at home, I'd restrict all access to my LAN, 
for a starter.  Now I have been producing XML reports with CSS.  But 
they're not connected to my web server at all.  I leave them as files on 
the hard drive, accessible only to local users who can use file:/// URLs. 
Occasionally I produce updated ones.

> 
> Hope to see more support for development of an API. As I am pursuing my
> Accounting degree at the moment ... I unfortunately cannot partake in a
> big way (at least I'll tlel the wife I can't!) right at this moment.
> But, if I can get a sense that this community is really behind this,
> I'll be more than happy to drop everything and contribute. It's crazy,
> I've been an IT professional for over 10 years, and I'm now pursuing my
> Accounting degree, what an awsome mix!

IT and Accounting would indeed be good skills combination.

-- hendrik