Hi Matt,
Now I got it. Seems to be exactly what I was looking for. I will have a closer look at it tomorror (it’'s 4:30 am here).
For the policy. Not that I would need it very urgently. But I think it would be a great deal of convenience for developing the ‘‘standard’’ chat-client. I would imagine it in a way perhaps a little similar to swings Component-Model architecture:
DefaultConnectionListener extends CL {
connectionClosed(){
// Do reconnecting according to default-policy
// and notify the user-Listener via the connectionOpened() method
// same thing for closedOnError()
}
}
The DefaultConnectionListener would be added to any connection by default.
Adding an connectionOpened() method to the CL would have the additional advantage, that the connect method could run asynchonous. I feel, that such a method whouldn’‘t do harm anyway (gives a little bit more symetry: imagine two listeners. One of them reconnects. What’'s the simplest way for the other one to take notice of it?)
Of cause there has to be a way of removing this default-behaviour, but the ‘‘normal’’ client would be much simpler to implement:
class Client extends CL {
main(){
c = connect();
c.addConnectionListener( this )
}
connectionOpened(){
//do visual Stuff: e.g. showLink
}
connectionClosed(){
//do visual Stuff: e.g. hideLink
}
}
instead of having the reconnection methods build in a way
that thy can be called every disconnect.
So much for my 5 cents. But like I saied: I don’'t feel an urgent need for that. I do have to implement this stuff by my own since I have to fit spezial needs. It would eventually a little bit easier this way, but the main work lies somewhere else.
Anyway. I do really like this library and think it’'s great work.
Regards,
Florian