XML-RPC interface (was: Will GnuCash ever work for me?)

[Dave Peticolas]

--=-bfIR9XBYN0mG+q7AUgAh
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2001-09-26 at 08:31, Derek Atkins wrote:
> Dave Peticolas <dave@krondo.com> writes:
>=20
> > I don't think we are completely clean on this. We still have a few
> > globals, like the commodity table and the GUID->entity hash table.
>=20
> When I was working on the RPC Server I had noticed this.  It was a
> PitA.  I would _definitely_ support a session object (whether it's a
> gnc-book or something "above" it), that contains the commodity table
> and GUID table.
>=20
> In thinking about it, and thinking about how books work, I believe it
> is possible that multiple books can share a namespace (e.g.  when you
> copy a book from one place to another).  Therefore, session should be
> broken out of gnc-book, and the "globals" should be moved into
> sessions.

The entity hash is clearly session data. However, I think the commodity
table properly belongs to a dataset, since two gnucash datasets can have
'matching' commodities that differ in important details, like smallest
fractional amount.


> This would also require a 'major' API re-work, because everywhere that
> UIDs are used it would require a session pointer.  At least, this was
> true when I was seriously working on the RPC backend.

Yes.


> > that is part of a gnucash data set. I think it is conceptually
> > cleaner to have a top-level data object that represents an entire
> > gnucash dataset, independent of a session, like account groups
> > did before.
>=20
> I agree.  Question: can you think of cases where a GnuCash client (UI)
> would have multiple sessions opened at once?  I can certainly think of
> cases where a "server" would (e.g. RPC Server).
>
> This does lead to an interesting question: when would multiple books
> be considered a part of the same session, and when would they be part
> of different sessions (one client)?

I was still thinking there would be exactly one book per session.
Otherwise I think things could get very complicated.

dave


--=-bfIR9XBYN0mG+q7AUgAh
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQA7slTn5effKKCmfpIRAkkbAJ4+DuflTa0tHiTkV6w2jnIdX3dSegCdF2XJ
7+QnYjJDo7EKS0FQpfdtVKk=
=ID8K
-----END PGP SIGNATURE-----

--=-bfIR9XBYN0mG+q7AUgAh--