Re: A Customer's Request For Open Source Software

["Robert I. Eachus" <rieachus@attbi.com>]

Marin David Condic wrote:

> For that, I'd think a 32-bit address space ought to be sufficient. But 
> if you're doing dynamic allocation and you code things properly, 
> switching to a bigger address space ought to be near trivial.

To answer both Marin and Matthew together, yes, under Windows Server you 
can get a 3 Gig process space, but it isn't supported well.  However, 
that is why I was gushing about the AMD64 architecture.  Programs that 
are currently limited to two (or three) Gig, can have a 4 Gig process 
space under the beta of Windows 2003.  No recompiles, no nothing.  Even 
handier, as I pointed out, you can have a DLL that uses 64-bit 
addressing, and returns data copied into the 4 Gig process space.

To use the example of scanned receipts, they wouldn't have to take a 
chunk out of the 4 Gig accounting process address space, just run the 
program to display them in its own 32-bit OR 64-bit address space.  If 
you want to phrase that in Ada, you can have a distributed architecture 
where everything is running on the same system, but different parts of 
the application each have their own address space.  If you happen to 
have a dual or quad processor system fine, but even on a single CPU 
system you get the addressing benefits.  (Yes this code would work on 
Intel chips as well, but the PAE overhead is a killer.)

Combine that with a transaction/journalling system that is very 
lightweight and can use memory-mapped NVRAM, and I think we have a 
winner.  Works something like this.  The database can have per record 
locking.  The transaction system writes the journal entry, then updates 
the database unlocking the entries, and finally the transaction writes a 
completion.  Or, of course, the trasaction fails for some reason and the 
entry is overwritten, or preferably, logged as failed with the reason. 
If you have a small (Compact Flash card maybe?) NVRAM, the transaction 
process can write the log to disk--preferably two disks--when the 
contents of the NVRAM get full.  But my preference is to write the 
entire database out when the session is done, without, of course, 
overwriting the current version on disk.  With proper design, you can 
have a complete journalling and audit trail system with little or no 
user involvement.


-- 
                                               Robert I. Eachus

"As far as I'm concerned, war always means failure." -- Jacques Chirac, 
President of France
"As far as France is concerned, you're right." -- Rush Limbaugh