I have no objection to the 'Data Store API'. If you plan to really
build a Data Store API, and along side you happen to build an
experimental (or reference) implementation that uses the API and it
happens to use a 'transaction-per-directory' model, that's fine with
me. It shows that the API works. It also means that as an
open-source person, I can re-implement the data-store to a more
scalable solution ;)
The important thing, IMHO, is that API -- it needs to be designed
appropriately. Even though I know nothing about SQL databases, I'm
willing to teach myself in order to provide (hopefully) valuable input
to the API design. OTOH, I think the API is probably fairly obvious
;)
-derek
[EMAIL PROTECTED] writes:
>
> It's been rumoured that Christopher Browne said:
> > c) By virtue of being different, it encourages the decoupling of
> > front end from back end, which is Highly Desirable.
>
> OK, you convinced me. Its a good idea.
> Note, though, the 'engine' is already mostly (I want to say 'completely')
> decoupled from the 'persistance model' (aka file format or sql back end).
>
> The engine should be able to trivially support the
> transaction-per-directory data persistance model.
>
> The engine may need extensions to handle random access to stored
> data (e.g. to pull out onlyu a small subset of sql records). Although,
> come to think of it, if the 'Query' object is used consistently by the
> GUI, (and I think it is) then tweaking shouldn't be necessary.
> Although, reqalisitcally, tweaks will probably be needed.
>
>
> --linas
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
>
>
--
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 N1NWH
[EMAIL PROTECTED] PGP key available
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
