/************************************\ | Visual DialogScript Database Project | \************************************/ The purpose of this text file is to give details on the "Visual DialogScript Databse Project" for prospective team members. The reason for this project is to create a database system for VDS written in VDS. The constriant of of the project are as follows: The system must be: easy to use robust/stable updateable optimized The way this will be implimented will be via the use of HTML 4.0 tables. These provide a simple, structured storage format and also provides an easy method of viewing the complete database if required. This format does not however does not cater for data typing or field length restrictions. In most cases this will not be a problem as data typing and filed lengths are not a considerations. However provisions for both will be included in the database developers SDK in the form or units or routines that can be used to check data types and string lengths. The best way to define the format fully is to work through an example:
Heading1Heading2
Field1Field2
Field1Field2
Note the first tag contains a TITLE= Parameter. This is not normally included in the TABLE tag, however it is still a legal use of the TITLE parameter in HTML 4.0. The inclusion of the TITLE parameter is to allow easy identification of tables, particulary in HTML files that contains more than one table. The first record (data within tags)(record 0) does not contain the normal tags instead it contains tags. These are used to define the name or heading of each column which can also be used a s a reference when editing individual fields. The following records all contain only tags with the actual data in between them. The number of tags pair must correspond with the number of tag pairs. The last line contains th close table tag The first incarnations of the database engine will not support tables within tables but later version may do. The purpose of the engine is to provide a simple interface between VDS and the above data format. Such as ^DB_ADD(some.html,TABLE1,Field1|Field2) would add a new record to the database table. The database engine upateabilty is also very importent. It is un-exceptable for script using the engine to require re-writting or even just recompiling with ever reales of the database engine. For this reason the database engine will be an external exe file from the scripts that use it. A VDU Converter Module will be used to convert the simple commands like the one above to a format that can be used by the DB engine. Communication between the DB engine and user scripts will be handled by a system implimenting vdsxregv.dll local variable pool sharing. Each user script when run will run a hidden copy of the DB engine with the command: RUNH @REGVAR(PROCESS) This will pass the locator for the local variable pool for the user script. The path to the engine along with other details will be held in the registry. The engine will constantly check (in IDLE mode set by "OPTION PRIORITY") a variable in the user scripts variable pool for a command. When a command is found it is processed and the result put into an output variable and the input variable is cleared. This signals the user script that the process is complete and it can carry on. Commands involving the potential return of multi-line result will place the data in a temporary text file and use the output variable to flag the user script to its path and name. An example of this regvar system from a user script is as bellow: REGVAR LOCAL, DB_COMMAND, ADD|some.html|TABLE1|FIELD1;FIELD2) repeat until @not(@null(@regvar(local,DB_OUTPUT))) %R = @regvar(local, DB_OUT) REGVAR LOCAL, DB_OUT,"" The conversion of the simple command to the above script would be handled either by the VDU Converter or by a database VDU Convert Module. The engine will also have the ability to encrypt tables with an implimentation of the Blowfish algorithm wich is extremly secure for almost all situations. The encrypted data will be in this format within the HTML file: {Encrypted data}
the tags remain to maintain easy extraction of the data. Again this may not be in the first release. The First release will have the following abilities: 1)Create new HTML files (with table data in) 2)Add new tables to a pre-created HTML file 3)Add records to a table 4)Delete records from a table 5)Edit whole records It will support any data that can be represented in ASCII format. It might support a basic implimenation of the encryption system. Subsiquent releases will include: Full encryption support Support for external data files (eg binaries and multi-line text) Editing of individual field instead of entire records A Record/Database locking system and much more... If you would like more information or would like to get involved please contact me on: Xiris@zetnet.co.uk any comments or suggestions are welcome as they always are.@n‹§uªò ´N@×ß|^@ßp7Ô=çN