Major development & Function testing

We finished to develop the list of references for the Task and currently testing it. How much should we care about the infinite recursion?
I mean if a Task1 has a subtask Task2. And the Task2 has Task1 as a subtask? Do we have to care or do we believe that the admin will be smart enough?

---

We deleted the tasklist.Observation and contact.Observer. We had to solve quite a huge amount of conflict around the project after that!!'''
Still working on that

---

Split the TaskList? from XMLBeans and tasklist.Task. It means we'll build the tree of tasklist.Task in the UnmarshallerBeans? instead of inside the Task.

---

We currently have a problem which was supposed to be solved... Apparently after changing x times the schema , we can't read a tasklist using XMLBeans anymore Therefore we 're working actively on that

---

Cleaned all the occurences of MimeTypes?!!

---

We're studying the solution of recursion and adaptation of the RequestList?.
Recursion

Con's	Pro's
1. would effect major changes in the UnicornCall?	1. would be more natural to program
2. would break the design patterns and architecture of the application

RequestList? adaptation

Con's	Pro's
1. May rise a problem for the level of execution	1. would effect minor changes in the UnicornCall?
2. Create a new algorithm to deal with conditional nodes	2. would suit the architecture of the application

We're studying an hybrid solution. One which would create recursively a RequestList? for each level of execution. That might be the solution.

---

Here is the hybrid solution:
We'll browse the tasklist tree recursively in order to keep the link between the if and all that. At each recursion we'll generate a RequestList? which will contain the exec of this level and the if condition for the next level. We'll check the result of the "if" by applying the condition. If it matches we'll call the same method on the ifOK node. on the contrary we'll call the ifnotOK node in the function.
Don't forget to check that the node is not null at the beginning. If it is , just return
This way we'll keep the simple architecture already settled in the project and we'll also add the simplicity of the recursion. Therefore it might be easy to understand and quite clear. However this will cause major changes in the UnicornCall? class.