Re: Questions about gnuCash backend access

2007-09-03 Thread Josh Sled
Daniel Espinosa [EMAIL PROTECTED] writes:
 QOF headers has a lot of coments pointing potencial bugs or even
 actual bugs Can I add this as bugs in bugzilla?

I'm not sure what the advantage would be to having them either in two places
(the comment and bugzilla) or one place (bugzilla) which is separate from the
code.  If you want to submit a patch that addresses a bug, it might be good
to create a bugzilla entry as a place to attach the patch ... but mailing it
to gnucash-devel is probably just as good.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgpRg6fI0oKZZ.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-31 Thread Daniel Espinosa
2007/8/29, Josh Sled [EMAIL PROTECTED]:
 Daniel Espinosa [EMAIL PROTECTED] writes:
  Well I still wait for my patch to be applied to QofCollection (see bug
  #453502) and wants to alling the current API convention to GObject's
  one (see bug #470788).

 (alling isn't an English word.  What do you mean?)


I mean, is it convenient? is it usefull to use conventions from GObject?

I think an exposed API must be as mininal as possible, but feature
rich, clean and not expose any potencial dangerous functions used
just in the core's internals.

I'm writing a test program to use the actual API, measure its
usability and file bugs if potencial.

QUESTION:

QOF headers has a lot of coments pointing potencial bugs or even
actual bugs Can I add this as bugs in bugzilla?



 Regardless, there's no *requirement* that we change the convention.  They're
 just that ... conventions.  At the same time, most of us do want to change
 the names and what not, but there are better and worse times to do it.


I'm the one who wants to change a lot of internals and exposed
externals, and yes I think there's better time than other to make
changes, but the main developers must agree what and where (defining
the future of the core) and start aa quick as possible, becouse we
need to spent a lot of time.

-- 
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (entrámite, pero para los
cuates: LIBRE)

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-29 Thread Josh Sled
Daniel Espinosa [EMAIL PROTECTED] writes:
 Well I still wait for my patch to be applied to QofCollection (see bug
 #453502) and wants to alling the current API convention to GObject's
 one (see bug #470788).

(alling isn't an English word.  What do you mean?)


Regardless, there's no *requirement* that we change the convention.  They're
just that ... conventions.  At the same time, most of us do want to change
the names and what not, but there are better and worse times to do it.

-- 
...jsled
http://asynchronous.org/ - a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED]


pgp0nyZxxgn2r.pgp
Description: PGP signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-27 Thread Daniel Espinosa
2007/8/26, Derek Atkins [EMAIL PROTECTED]:
 Daniel Espinosa [EMAIL PROTECTED] writes:

  2007/8/24, Derek Atkins [EMAIL PROTECTED]:
 [snip]
  Agreed.  We really need a viable multi-user backend for GnuCash.
 
  What do you think is the BETTER way to do so?

 A GDA Backend.

  Having said that, GnuCash does not currently have a supported
  multi-user backend.  That WOULD be a requirement, so I encourage
  you to help Phil Longstaff complete the GDA Backend in the gda-dev
  branch.
 
  You say: multi-user backend, but it isn't the same that a
  multi-user enviroment , I think the solution is:

 I think it depends on your definition of environment.  To me,
 I imagine a multi-user environment would be something like a
 small business office where multiple people need access to the
 same data file.  That's an environment.  It has nothing to do
 with the actual implementation or coding; it's all a question of
 how the system needs to be used.

 A multi-user backend is a specific implementation.  It would be
 an upgrade of the old Postgres backend, migrating it from pure
 postgres to GDA.

  a) Create a GnuCash Server a la Evolution, this allows any application
  to use the GC's data, but this enviroment just allow connections from
  the same computer and in a bussines software like GnuCash, you will
  need to get multiple connections from diferent computers (the
  accountant, the cashier, the owner, etc.)

 I don't think this is necessary, and I think it would be overkill
 for the vast majority of users.  It would imply a fairly major
 architectural change to GnuCash and I don't think the gain would
 justify the cost at this time.

  b) Allow GnuCash to connect to a database server, in this escenario
  each user will get a GUI frontend (actual GC's GUI) and will share
  data with others using the multi-user enviroment by the dabase server
  (this will be archived by the GDA backend), but it doesn't allow any
  other application to use the GC's data and make sure it is using it in
  the way GC does, keeping the data consistency and run the riquired
  actions actualy in the GC's engine.

 This is required, and this is exactly what the GDA backend would
 supply.  This is why I'm pushing it so hard.

  c) Allow multiple applications to connect to the GC's data by an API,
  the data must be stored in a database server to get a multi-user
  enviroment. With this any application can use the data in a consistent
  way and doing just GC's engines wants to. As an adition you can allow
  anyone to create the GUI according with its inviroment.

 We already have this now..  Someone could write an application and
 link against the gnucash engine APIs and then load and use gnucash
 datasets.  We would tie into a database through a GDA backend, just
 like we currently tie into an XML file via the File Backend.  There's
 no new coding necessary to get this working, it's all there right now.


BUGS! (please refer to bugzilla for details):

a) #470753 - There isn't any gnucash.pc file anywhere to export the actual API.
b) #470750 - The actual documentation talks about some non-existent
functions for gnc_book
c) #470755 - Add support for multi-user access
d) #470760 - Actual API doesn't allow to use GC's data

As you can see we need to fix them before to say it's all there right now.

  QOF dataset query engine is very limited and we want GDA give QOF with
  the multiuser features GC needs, I think that GDA must replace QOF.
  GDA can give us the same functionalities: datasets and queries, but in
  a powerfull version, and the multi-user features required by GnuCash.

 This is arguable.  I've still never seen an application proposal that
 couldn't use the existing infrastructure.  You keep asserting over and
 over that you can't do it with QOF, but neither you nor anyone else
 has shown a concrete proposal for a real application that you intend
 to write that requires more than what QOF provides.


If an external application needs to access the GC's data must do it
using engine's API not QOF, then I found the following:

MORE BUGS! (please refer to bugzilla for details):

e) #470767 – Actual engine API doesn't export any function or gives a
way to get access to the QOF datasets and or create a QofQuery.

f) #470780 - Improve SQL support in QofQuery

Most of this bugs could be fixed using GdaDataModel and GdaQuery, and
inmediately access to tables, fields, rows or any object like triggers
in the database manipulation using GDA's GObjects.

I realy want Gnumeric or even OpenOffice, to get access to GC's data
and use their powerfull financial functions to get great financial
analisys, more sofisticated graphs, tendencies and more. QOF or
GnuCash doesn't allow give any method to share data with this
applications. GDA has some integration level with Gnumeric.

An applet will be usefull in order to help end user to quickly
register simple transactions without run GnuCash's GUI and at the same
time could show some graphs about your 

Re: Questions about gnuCash backend access

2007-08-26 Thread Derek Atkins
Daniel Espinosa [EMAIL PROTECTED] writes:

 2007/8/24, Derek Atkins [EMAIL PROTECTED]:
[snip]
 Agreed.  We really need a viable multi-user backend for GnuCash.

 What do you think is the BETTER way to do so?

A GDA Backend.

 Having said that, GnuCash does not currently have a supported
 multi-user backend.  That WOULD be a requirement, so I encourage
 you to help Phil Longstaff complete the GDA Backend in the gda-dev
 branch.

 You say: multi-user backend, but it isn't the same that a
 multi-user enviroment , I think the solution is:

I think it depends on your definition of environment.  To me,
I imagine a multi-user environment would be something like a
small business office where multiple people need access to the
same data file.  That's an environment.  It has nothing to do
with the actual implementation or coding; it's all a question of
how the system needs to be used.

A multi-user backend is a specific implementation.  It would be
an upgrade of the old Postgres backend, migrating it from pure
postgres to GDA.

 a) Create a GnuCash Server a la Evolution, this allows any application
 to use the GC's data, but this enviroment just allow connections from
 the same computer and in a bussines software like GnuCash, you will
 need to get multiple connections from diferent computers (the
 accountant, the cashier, the owner, etc.)

I don't think this is necessary, and I think it would be overkill
for the vast majority of users.  It would imply a fairly major
architectural change to GnuCash and I don't think the gain would
justify the cost at this time.

 b) Allow GnuCash to connect to a database server, in this escenario
 each user will get a GUI frontend (actual GC's GUI) and will share
 data with others using the multi-user enviroment by the dabase server
 (this will be archived by the GDA backend), but it doesn't allow any
 other application to use the GC's data and make sure it is using it in
 the way GC does, keeping the data consistency and run the riquired
 actions actualy in the GC's engine.

This is required, and this is exactly what the GDA backend would
supply.  This is why I'm pushing it so hard.

 c) Allow multiple applications to connect to the GC's data by an API,
 the data must be stored in a database server to get a multi-user
 enviroment. With this any application can use the data in a consistent
 way and doing just GC's engines wants to. As an adition you can allow
 anyone to create the GUI according with its inviroment.

We already have this now..  Someone could write an application and
link against the gnucash engine APIs and then load and use gnucash
datasets.  We would tie into a database through a GDA backend, just
like we currently tie into an XML file via the File Backend.  There's
no new coding necessary to get this working, it's all there right now.

 QOF dataset query engine is very limited and we want GDA give QOF with
 the multiuser features GC needs, I think that GDA must replace QOF.
 GDA can give us the same functionalities: datasets and queries, but in
 a powerfull version, and the multi-user features required by GnuCash.

This is arguable.  I've still never seen an application proposal that
couldn't use the existing infrastructure.  You keep asserting over and
over that you can't do it with QOF, but neither you nor anyone else
has shown a concrete proposal for a real application that you intend
to write that requires more than what QOF provides.

So, at this time I still don't see this as a short-term or medium-term
goal.  It still feels like a solution in need of a problem, and it
looks like a lot of work just to migrate from one dependency to
another, for very little gain in the user experience or change in the
API.

I think you'd be better off, in the short term, migrating more object
APIs over to Gobject, or working on the GDA backend with Phil.

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-25 Thread Daniel Espinosa
2007/8/24, Derek Atkins [EMAIL PROTECTED]:
 Quoting Daniel Espinosa [EMAIL PROTECTED]:

  2007/8/24, Samuel deHuszar Allen [EMAIL PROTECTED]:
  I am a Lotus Notes / web developer.  Have built a custom Notes app for
  invoicing and billing and am wondering if there is a programmatic way to
  create transactions and records in gnuCash.  If so, what languages/tools 
  are
  needed to talk to the program?   I am also curious how transactions are
  stored internally.  XML?  Ideally, I would like to create a connection that
  would allow either the Domino server, or a server agnostic webservice to
  write and retrieve information from mobile devices/web forms.
 
 
  For thease reason and others in the mailing list (one about to have an
  applet), is realy important to allow simultaneous multiaccess to the
  GnuCash data.

 Agreed.  We really need a viable multi-user backend for GnuCash.


What do you think is the BETTER way to do so?

  Allowing other apps to use a library to connect to the data for
  consult or modify, without need to run ANY GUI is one of the best
  solution. I think the use of a GDA based interface could be usefull,
  any could create powerfull (near to the standard SQL instructions)
  queries for insert, update or delete, using GdaQuery, connect to the
  database backend using GdaDict. This library *must* ensure the data
  integrity and, I think, works as a layer between the applications and
  GC's data.

 I'll point out, YET AGAIN, that GDA is NOT necessary to solve this
 problem.  One could just as easily write a new application against
 the existing GnuCash APIs and create their own application that
 doesn't use the standard GnuCash GUI.


I realy considering to do that. I don't know way you think that but...

 Having said that, GnuCash does not currently have a supported
 multi-user backend.  That WOULD be a requirement, so I encourage
 you to help Phil Longstaff complete the GDA Backend in the gda-dev
 branch.


You say: multi-user backend, but it isn't the same that a
multi-user enviroment , I think the solution is:

a) Create a GnuCash Server a la Evolution, this allows any application
to use the GC's data, but this enviroment just allow connections from
the same computer and in a bussines software like GnuCash, you will
need to get multiple connections from diferent computers (the
accountant, the cashier, the owner, etc.)

b) Allow GnuCash to connect to a database server, in this escenario
each user will get a GUI frontend (actual GC's GUI) and will share
data with others using the multi-user enviroment by the dabase server
(this will be archived by the GDA backend), but it doesn't allow any
other application to use the GC's data and make sure it is using it in
the way GC does, keeping the data consistency and run the riquired
actions actualy in the GC's engine.

c) Allow multiple applications to connect to the GC's data by an API,
the data must be stored in a database server to get a multi-user
enviroment. With this any application can use the data in a consistent
way and doing just GC's engines wants to. As an adition you can allow
anyone to create the GUI according with its inviroment.

QOF dataset query engine is very limited and we want GDA give QOF with
the multiuser features GC needs, I think that GDA must replace QOF.
GDA can give us the same functionalities: datasets and queries, but in
a powerfull version, and the multi-user features required by GnuCash.

I'm actualy working in a library to get the same functionalities in
GC's engine but using directly GDA. This library must export an API to
be used by any application to get access to the data.

-- 
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (entrámite, pero para los
cuates: LIBRE)

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Questions about gnuCash backend access

2007-08-24 Thread Samuel deHuszar Allen
I am a Lotus Notes / web developer.  Have built a custom Notes app for
invoicing and billing and am wondering if there is a programmatic way to
create transactions and records in gnuCash.  If so, what languages/tools are
needed to talk to the program?   I am also curious how transactions are
stored internally.  XML?  Ideally, I would like to create a connection that
would allow either the Domino server, or a server agnostic webservice to
write and retrieve information from mobile devices/web forms.

Any information to these ends would be greatly appreciated.  And to be sure,
any webservice bridge I cobble together will be made available to the
public.  :)

My normal business email is [EMAIL PROTECTED], but we've had some
storms in the Chicago area and my mail server is out until the power comes
back up.  Please respond to [EMAIL PROTECTED]

Thanks in advance,
Samuel deHuszar Allen
[EMAIL PROTECTED]
773.793.0604
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-24 Thread Derek Atkins
Quoting Samuel deHuszar Allen [EMAIL PROTECTED]:

 I am a Lotus Notes / web developer.  Have built a custom Notes app for
 invoicing and billing and am wondering if there is a programmatic way to
 create transactions and records in gnuCash.  If so, what languages/tools are
 needed to talk to the program?

There is a C API and a Scheme API.

I am also curious how transactions are
 stored internally.  XML?

Nah, XML is just a storage mechanism.  Internally it's stored in a QOF
dataset.

 Ideally, I would like to create a connection that
 would allow either the Domino server, or a server agnostic webservice to
 write and retrieve information from mobile devices/web forms.

 Any information to these ends would be greatly appreciated.  And to be sure,
 any webservice bridge I cobble together will be made available to the
 public.  :)

 My normal business email is [EMAIL PROTECTED], but we've had some
 storms in the Chicago area and my mail server is out until the power comes
 back up.  Please respond to [EMAIL PROTECTED]

 Thanks in advance,
 Samuel deHuszar Allen
 [EMAIL PROTECTED]
 773.793.0604

-derek

--
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-24 Thread Daniel Espinosa
2007/8/24, Samuel deHuszar Allen [EMAIL PROTECTED]:
 I am a Lotus Notes / web developer.  Have built a custom Notes app for
 invoicing and billing and am wondering if there is a programmatic way to
 create transactions and records in gnuCash.  If so, what languages/tools are
 needed to talk to the program?   I am also curious how transactions are
 stored internally.  XML?  Ideally, I would like to create a connection that
 would allow either the Domino server, or a server agnostic webservice to
 write and retrieve information from mobile devices/web forms.


For thease reason and others in the mailing list (one about to have an
applet), is realy important to allow simultaneous multiaccess to the
GnuCash data.

Allowing other apps to use a library to connect to the data for
consult or modify, without need to run ANY GUI is one of the best
solution. I think the use of a GDA based interface could be usefull,
any could create powerfull (near to the standard SQL instructions)
queries for insert, update or delete, using GdaQuery, connect to the
database backend using GdaDict. This library *must* ensure the data
integrity and, I think, works as a layer between the applications and
GC's data.

 Any information to these ends would be greatly appreciated.  And to be sure,
 any webservice bridge I cobble together will be made available to the
 public.  :)

 My normal business email is [EMAIL PROTECTED], but we've had some
 storms in the Chicago area and my mail server is out until the power comes
 back up.  Please respond to [EMAIL PROTECTED]

 Thanks in advance,
 Samuel deHuszar Allen
 [EMAIL PROTECTED]
 773.793.0604
 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel



-- 
Trabajar, la mejor arma para tu superación
de grano en grano, se hace la arena (R) (entrámite, pero para los
cuates: LIBRE)

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-24 Thread Derek Atkins
Quoting Daniel Espinosa [EMAIL PROTECTED]:

 2007/8/24, Samuel deHuszar Allen [EMAIL PROTECTED]:
 I am a Lotus Notes / web developer.  Have built a custom Notes app for
 invoicing and billing and am wondering if there is a programmatic way to
 create transactions and records in gnuCash.  If so, what languages/tools are
 needed to talk to the program?   I am also curious how transactions are
 stored internally.  XML?  Ideally, I would like to create a connection that
 would allow either the Domino server, or a server agnostic webservice to
 write and retrieve information from mobile devices/web forms.


 For thease reason and others in the mailing list (one about to have an
 applet), is realy important to allow simultaneous multiaccess to the
 GnuCash data.

Agreed.  We really need a viable multi-user backend for GnuCash.

 Allowing other apps to use a library to connect to the data for
 consult or modify, without need to run ANY GUI is one of the best
 solution. I think the use of a GDA based interface could be usefull,
 any could create powerfull (near to the standard SQL instructions)
 queries for insert, update or delete, using GdaQuery, connect to the
 database backend using GdaDict. This library *must* ensure the data
 integrity and, I think, works as a layer between the applications and
 GC's data.

I'll point out, YET AGAIN, that GDA is NOT necessary to solve this
problem.  One could just as easily write a new application against
the existing GnuCash APIs and create their own application that
doesn't use the standard GnuCash GUI.

Having said that, GnuCash does not currently have a supported
multi-user backend.  That WOULD be a requirement, so I encourage
you to help Phil Longstaff complete the GDA Backend in the gda-dev
branch.

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-24 Thread Derek Atkins
Hi,

Please remember to CC the list on all your replies...

Samuel deHuszar Allen [EMAIL PROTECTED] writes:

 First, thanks for the quick response.  A quick perusing through the Scheme
 language docs makes me wonder.  What's the best way to inject procedures?  Is
 learning Scheme a worthwhile endeavor? Or are there some quick bindings that I
 can access using some common (non-C++ as I am a C-Dummy) XML exchange such as
 SOA, SOAP, etc.?  Can I use gnome GUI tools to invoke commands or scripts?  I
 want to be able to create a web-based interface, or some kind of transaction
 broker that can inject/retrieve information from a local gnucash
 installation.  It looks like there's no gnucash server of any kind.

You can get GnuCash to load new scheme procedures at runtime.  It's
not the EASIEST thing in the world, but it's possible.   Note also
that I said C, not C++.

IMHO learning Scheme is always a good idea.  It's a very useful
language to know from a Computer Science point of view.  It's very
easy to learn (it should take a good programer no more than a day to
really learn the syntax, and a week to learn the basic APIs).

Adding SOA/SOAP etc. to gnucash would be MUCH more challenging.
GnuCash (as-is) is a desktop applkication, not a web-app.  No, there
is no gnucash server.

 Without C++ knowledge, am I sunk?  Thanks again for your help, and my
 apologies for hand-holding requests.  If I don't have to learn an enormous
 high-level programming language to do what I want, I'd prefer to not.  :)

See above.  There is no C++, there is only C.  But if you don't
know C and aren't willing to learn Scheme, then yes, you're SOL.

 Thanks again.

 Sincerely,
 Sam

-derek

-- 
   Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
   Member, MIT Student Information Processing Board  (SIPB)
   URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
   [EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


Re: Questions about gnuCash backend access

2007-08-24 Thread Samuel deHuszar Allen
Thanks for the feedback.  I didn't know I was mailing to the gnucash list.
I just clicked on the developer's mailto on the support site.  I guess I've
got some reading material ahead of me this weekend.  :)

Sam

On 8/24/07, Derek Atkins [EMAIL PROTECTED] wrote:

 Hi,

 Please remember to CC the list on all your replies...

 Samuel deHuszar Allen [EMAIL PROTECTED] writes:

  First, thanks for the quick response.  A quick perusing through the
 Scheme
  language docs makes me wonder.  What's the best way to inject
 procedures?  Is
  learning Scheme a worthwhile endeavor? Or are there some quick bindings
 that I
  can access using some common (non-C++ as I am a C-Dummy) XML exchange
 such as
  SOA, SOAP, etc.?  Can I use gnome GUI tools to invoke commands or
 scripts?  I
  want to be able to create a web-based interface, or some kind of
 transaction
  broker that can inject/retrieve information from a local gnucash
  installation.  It looks like there's no gnucash server of any kind.

 You can get GnuCash to load new scheme procedures at runtime.  It's
 not the EASIEST thing in the world, but it's possible.   Note also
 that I said C, not C++.

 IMHO learning Scheme is always a good idea.  It's a very useful
 language to know from a Computer Science point of view.  It's very
 easy to learn (it should take a good programer no more than a day to
 really learn the syntax, and a week to learn the basic APIs).

 Adding SOA/SOAP etc. to gnucash would be MUCH more challenging.
 GnuCash (as-is) is a desktop applkication, not a web-app.  No, there
 is no gnucash server.

  Without C++ knowledge, am I sunk?  Thanks again for your help, and my
  apologies for hand-holding requests.  If I don't have to learn an
 enormous
  high-level programming language to do what I want, I'd prefer to
 not.  :)

 See above.  There is no C++, there is only C.  But if you don't
 know C and aren't willing to learn Scheme, then yes, you're SOL.

  Thanks again.
 
  Sincerely,
  Sam

 -derek

 --
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board  (SIPB)
URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH
[EMAIL PROTECTED]PGP key available




-- 
Samuel deHuszar Allen

If I don't have the right solution,
you have the wrong problem.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel