It's been rumoured that Alexander L. Belikoff said:
> I've been thinking a lot recently about a way of doing such things
> right. Now it seems to me the right approach would be splitting the
> application by two distinct parts: and engine and "clients".
>
> Here by an "engine" I don't mean just Linas's API for accounts
> management. Instead, I mean something like a server, which manages
> accounts. This server knows about file (or database) I/O, it knows
> nothing about GUI, it doesn't care about WWW, and it supports a set of
> high-level API via sockets.
Yup. Exactly.
Question: What's the "high-level API over sockets"?
Wrong Answer: Invent one ...
The clue: Well, IIOP is a general-purpose tcpip-based transport
protocol ... and there's this nifty code called "IDL stub generator"
to translate from the API you define, to IIOP, and back again in the
other direction. You just write the API, and the engine behind it,
and the network stuff is automatic ... this magic technology is
called "corba".
> Ideally, it should allow loading shared
> modules w/ encryption, database I/O and additional import/export
> facilities.
By private email, someone wrote to state that they've almost finished
a little encryption engine for the file format...
> Once this is done, it'll be relatively easy to create clients using
> various GUI kits - all of them will use the same API.
Yes ... but it turns out that creating the gui kits are more than half the
work. For example, the engine today is maybe 1/4th of the total, and
that's not couting the "free" lines of code in Xbae, or XmHTML, (or PHP-3)
each one of which is bigger than all of gnucash combined.
--linas
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
