Data-Management.md

@@ -9,25 +9,43 @@ Data architecture :
 We thought about 3 possible solutions :
  1. Both the Core Simulation and the IAs has a physical access to the variable x. They can both modify it and get access to it. But IA shall not modify it.
 
-++ : It is really (really) quick at execution.
--- : The modules are not seperated. The IA shall not possibly modify this variable.
+++ : It is really (really) quick at execution, Easiest to implement
+-- : Modules have to be compile together. The IA shall not possibly modify this variable.
 
  2. The Data Management discussion came with the following idea : We use a central module which has access to all the datas, gives the data required when asked by a module. Datas are actualized when a variable is modified. (there s a existing module to do that efficiently) This module could be merged with Core Simulation if it decreases a lot the quantity of data exchanged.
 
-++ : It permits to have different programmation languages for each module. It is easier in the implementation for modularity.
--- : Time execution may be too long for real time game (is it less than 33 ms (30Hz) ?) 
+++ : It permits to have different programmation languages for each module. It is easier in the implementation for modularity.Fast enough if well implement see annexe.
+-- : Harder to implement on the data module side.
 
 3. Use a class system to allow only a getter to the IAs and the whole class to the Core Simulation.
 
 ++ : It can't be quicker, it is the same as a physical access but with no possible modification.
--- : It can be harder to implement, it may affect the modularity because it may force both module to be implemented in the same programmation 
-
-language.
+-- : It can be harder to implement, it may affect the modularity because it may force both module to be implemented in the same programmation language.
 
 Conclusion :
 
-I think that the second option is the most interesting, as it permits any module to do what they want on their own (and it would be the data 
+I think that the second option is the most interesting, as it permits any module to do what they want on their own (and it would be the data management group that would have to do the dirty work). But it needs to be really quick to be allowed. If it is not quick enough, I think we shall get to solution 3.
+
+Annexe:
+
+Data Structure: 
+We thought about 4 different type of data which will be store differently.
+
+—>Persistent Data, (SAVE, LOG, Chat ?, IA(2nd way to play not the real one))
+====== Most of this can be stored in a SQL Data base. which will allow fast and easy auto-save. (file might be consider too)
+—>Semi-Persistent Data (Characters stats, …)
+======Here we will store those information on SQL too, but the data will stay in cache as long as nobody requested it, as a module will eventually.
+—>Volatile Data (Character HP, position, speed,acceleration).
+======Most of this information which need fast access will be in cache. 
+—>Map
+======According to us map, is very particular and should be deal with separately, we thought about XML or AXML.
+
+Discusion about solution 2:
+
+It heavily depend on languages each sub module want to us. Few groups we were talking too, where up to do C++, if most of them would then it will easier our job.
+However we are willing to offer to each sub-module his own library in the language he wants to be able to communicate to our module and so to every module. Such libraries would share data thanks to SQL,XML,and shared memory (mmap), to optimize speed, it will be in C/C++.
 
-management group that would have to do the dirty work). But it needs to be really quick to be allowed. If it is not quick enough, I think we shall 
+We are well aware that it’s not usual to share data between submodule this way, most of the time each sub module would have to implement his own libraries in the Core language, however it might be a bit of a pain, so we offer an other solution.
 
-get to solution 3.
\ No newline at end of file
+After a few benchmark, the solution is fast enough (mmap) to share cache data between libraries therefore submodule. (as fast as a memory access would be in a compile share module).
+However lock (semaphore or mutex) to protect shared memory from multiple access were not implement.
\ No newline at end of file