I, too, like plan A. However instead of thinking about files, I'd
prefer if we did keep things in the abstract 'book'. A book could be
a file, it could be a database, it could be a remote database. You
don't know, and you shouldn't care. However, whatever we do should be
something that is tied into the backend. It would be nice if closing
books might even be a backend function, rather than an engine
function. I'm not sure.
-derek
Conrad Canterford <[EMAIL PROTECTED]> writes:
> Linas Vepstas wrote:
> <lots of good stuff about closing book options>
>
> Personally, I'd vote for Plan A (and not because I believe more work =
> better product).
>
> I'm already finding load times (both file and register) to be getting
> close to uncomfortably long, and I have only just (as in this month)
> exceed the 12 month mark. There is an option to fix the register load
> time, but not the file load time (well, not without doing option F
> manually, in any case).
> I rather suspect that although it is more work it is the long term
> better solution, but since I don't have any bright arguments to support
> this right at the moment I'm just going to state it as a fact and let
> others disagree.
>
> Conrad.
> _______________________________________________
> gnucash-devel mailing list
> [EMAIL PROTECTED]
> http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
--
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
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
