Correct repetitive bugs in Unicorn Call
We had to rebuild the whole dependance things with the classes
We had to correct the algorithm and think about the Response.

---

Does the if launch an observation or does it use a result previously executed?
I mean , the if does an observation or use an previous observation done by an exec?
The answer to this question will completly change the data structure and the algorithm to apply the condition in UnicornCall?.
Then we debate about that.

If the if doesn't perform an observation we'll just need of map of Response with the name of the observer as an ID.
Therefore the condition of the if will give us the name of the observation on which we'll have to apply the condition and we can search it in the map of Response.

Otherwise it's a little bit trickier to get the observer of the if to launch it but still quite easy to do.
We'll have a huge map of Response which will group all the response. This map will be filled thanks to the recursion on the tree.

---

We may have erased more mimetypes occurence than needed. Then we deleted a bit of check concerning the mimetype in UnicornCall?.
Then we have to re write it. Check the mapOfObserver to do the check observer.canHandleMimetypes.
Maybe we need to associate an Observer in the tree in order to keep the mimetypes things. In the tree we only have the String of the name of the observer. Should we put an Observer object instead? The mapofObserver is given in the tasklistUnmarshaller

---

We had to merge the version of Johnathan with mine , with minor problems... just took ages to do for each class.

---

After the merge and the algorithm in UnicornCall? we had a big cleaning to do in the class... still on it
We created a procedure to browse the Tree and create a RequestList? for each execution level / each node.
The problem is to keep going in the tree knowing that the answer is in the mapofResponse.
The new procedure should browse the tree, launch the Request, check the ifs of the current node and for each of them and analyze the response and recall itself on the new node.
Heavy recursion but might work.
We can externalize the launch of the Request , the condtional checking on the response.
However the procedure will still be heavy

---

We had a little specification problem. The way we did the UnicornCall? to browse the tree wasn't especially made to care about the condition.
Now that we're coding the conditional checking we have to adapt the UnicornCall? and do another algorithm to care the conditional checking now.
Johnathan is doing the conditional checking.
Me (Florent) I rewrite the whole UnicornCall? and clean it up while I'm on it.