From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,afb0cacfa5b1eece X-Google-Thread: f98db,afb0cacfa5b1eece X-Google-Attributes: gid103376,gidf98db,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!newscon06.news.prodigy.com!prodigy.net!newsfeed-00.mathworks.com!bigboote.WPI.EDU!news.tufts.edu!elk.ncren.net!newsflash.concordia.ca!pitt.edu!nn.andrew.cmu.edu!newsfeeder.srv.cs.cmu.edu!anon.lcs.mit.edu!nym.alias.net!mail2news X-SpamCatcher-Score: 2 [X] From: "Wa Benzi" Subject: 'Gard' - Genuine Ada Relational Database, semi-proposal X-Mailer: CommuniGate Pro WebUser Interface v.4.3.8 Date: Thu, 09 Mar 2006 07:59:51 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit Mail-To-News-Contact: postmaster@nym.alias.net Organization: mail2news@nym.alias.net Newsgroups: comp.lang.ada,alt.deposit Xref: g2news1.google.com comp.lang.ada:3301 alt.deposit:14 Date: 2006-03-09T07:59:51+02:00 List-Id: Some suggestions made regarding the DB and file system extensions to the AdaOS 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 OS. 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, OS/X as well as interim versions of AdaOS. 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]