Re-write connection/disconnection flow

[alexstrat]

Ideas :

• create an other state of the reactor : kind of pause state where RPCs are not sent for any reasons (transport disconnected).
• automatic re-connection after disconnection.. Related to Unexpected XMPP disconnection on idle iPhone #42

[alexstrat]

Now the transport part is a kind of sub-part of the reactor since it's instantiated in the reactor initialization. We should maybe separate and instantiate it in node and then pass it to the reactor as it.

[jinroh]

That may be a solution. However how should we handle the disconnection event emitted by the transport. Should it be managed internally by the transport and reported back if the problem persists, or handled by the reactor (or the node ??).
Hmm..

[alexstrat]

This was just a matter of inititialization and reference to the transport. The reactor will still be listening to the transport. It is only not responsible to instantiante it anymore (it will be the node) and the node has a direct reference to it in case of it wants listen to it.

It doesn't fix anything, I just find it simpler..

[jinroh]

I don't think I explained well my concern. I wanted to stress how should we handle a disconnection from the transport. For instance, if Strophe emits a disconnection event, should the transport try to reconnect by itself first and then if it didn't succeed tell the reactor, or should the reactor handle the whole reconnection process ?

[alexstrat]

Ahh..Ok. I'm deeply convinced that this should be handled by the transport itself, and the reactor (and other) gets feedback on this through new kind of events and states (reconnecting, ..).

[jinroh]

Agree, we have to write down all the states of the Tranport, Reactor and Node objects to clear the flow control.