Hi,after the new log system is now ready and Peter will take a look at the LDAP stuff in the future I can start the next major step towards 1.0 - the dataexchange rewrite.
We decided to put it in the database so I have two major ideas. First there should only be one PKI-wide configfile and second the database tables. If it is possible then we should make the solution as simple and robust as possible. Here now my idea:
1. dataexchange.xml openca ::= tree tree ::= node+ node ::= id . tree* . receive* . upload* id ::= normale module id download ::= dataexchange objecttype and status (e.g. APPROVED_REQUEST) upload ::= dataexchange objecttype and statusThe important thing is that we can calculate the datatypes which must be enrolled or received from the children of a node. This config file should always be enrolled. This guarantees that all nodes have the correct behaviour in the infrastructure because every node has the full overview.
2. database I think about the following: - key (a simple serial from a generator) - objecttype - objectstatus - objectkey - received (textkey) - upload (textkey) - downloaded (textkey)- enroll (textkey with length equals number of possible nodes divided by four)
The idea is that the commits are bitstrings which contain the same information like our todays log files of the dataexchange. Bit 18 contains a true or false for module id 18. The advantage is that there is only one row for every object and we can scan the different textkeys very fast.
If we want a more clean design which is perhaps a little bit slower then we need one table with the object infos and one table with the fields key (foreign key to object table) and module. The status or the direction are not required because there can only be two states between two nodes and these states can be simulated to be in the database or not (means successfully synchronized or not in the database).
Any comments please? It would be nice to hear from some people because last time the people only started testing if it was too late. The solution with two tables has at minimum the advantage that the people can check the state with a simple SQL CLI.
Greetings Michael -- _______________________________________________________________ Michael Bell Humboldt-Universitaet zu Berlin Tel.: +49 (0)30-2093 2482 ZE Computer- und Medienservice Fax: +49 (0)30-2093 2704 Unter den Linden 6 [EMAIL PROTECTED] D-10099 Berlin _______________________________________________________________
smime.p7s
Description: S/MIME Cryptographic Signature
