Some suggestions made regarding the DB and file system extensions to the AS project. I'd be
interested to know if there is any support in this forum for the idea of open relational database
and file system projects as described below:
I think it would be wise to start a separate project for 'Carrot', an Ada relational database.
Before coding, I think it would be useful to spec out a full design, in some detail. For an Ada
environment encryption would be an important topic - probably at a record level. Access rights and
security, boring as they are, are also important. If you have a distributed model then you don't
want a centralised locking mechanism - you want some kind of distributed locking, probably object
orientated lock requests at the record level - doing this with low overhead is an interesting
challenge - one well known solution is to never lock on reads, only on writes, and to assume that
all reads are tentative (that is they could have been overwritten just after the write) this
doesn't suit everybody, obviously (banking would be interesting, to say the least, in such an
environment). Solving the distributed locking problem would be worth while - I think a distributed
server approach with each server responsible for its own locking, security etc. environment would
make the most sense. Though they would be later stages of the project, it would be worth
considering concurrent on-line backup, contingency (disaster recovery) management, availability and
capacity management as part of the design - in other words, build metrics into the fabric of the
design, don't add them on afterwards. The important question of designing the database so that it
could make time-relative queries as part of its essential fabric would have to be considered as
well - to crack that in the design in itself might make it a huge commercial success!
I'd recommend making the file system a separate project too. File systems are not part of an S. It
is an important thing to have and there are so many mistakes to learn from. Linux, however, now has
some reliable, journalled file systems that can handle large volumes, striped volume sets, long
file names and so forth. It might be worth translating one - not a blind translation, more a
mapping of the Linux version to a detailed design, then a re-coding in Ada.
If you made a loose coalition of the three projects then they need not be dependant on each other.
The file system and db system could still run under linux, msdros, S/X as well as interim versions
of AS.
Why not put them onto sourceforge? Initially, you'd be looking at a 2-4 month design phase. I think
that quite a few experts might be encouraged to take part in advising and debating this phase
without a commitment to the development phase. That way you could be sure of a novel, reliable and
consistent design to both. If the design is right then the coding should be a doddle - if not, the
coding will be a nightmare!
In writing the project description, it might be worth while covering all the reasons why Ada is a
good choice for both - what does Ada bring to a file system and to a relation db system? Also,
design objectives for a fail-safe, highly reliable and low-error system would need to be made
explicit. If both the file system and db are designed in such a way that any of the designers would
be happy for their aeroplane or heart monitor to be reliant on the final product that might give
the right impression. There is little point in going for an Ada system that isn't rock solid from
the start - that is the design.
Careful consideration, at the design phase, would have to be given to error detection, recovery and
exception handling - after the initial design is finalised, I'd imagine quite a long period of dry
runs through edge cases, and unlikely but conceivable scenarios to establish exactly how error and
exception reporting and recovery would be handled. If these show design flaws, then the design
would have to be modified. These would have also to consider very high transaction volumes and what
they could do to the design.
You might wish to consider making these discussions private, under an NDA, there might be some
useful patents or papers as a spin-off.
Sent from UnionMail Service [http://mail.union.org.za]