Well, socket timeouts could continue to happen for any reasons: slow server, slow connection, giant reply message (does anyone ever delete old calendar entries?), etc. I think in general having /some/ reasonable way to handle timeouts is not a bad idea, even if the general case is DAVdroid connecting to fast servers over fast connections.
The timeouts you mention are handled in different ways:
- ConnectTimeout is the timeout value for connecting to the socket (regardless of the reply), i.e. if the timeout is 40, a server may take 39 seconds to reply with SYN+ACK, while
- SocketTimeout defines how long a read() call may block until a
SocketTimeoutException is thrown.
The first timeout is usually not a problem and a Web server thing, while the second one is given by the actual CalDAV/CardDAV application.
- Slow connection: the connection timeout applies. Please note that in case of a connection timeout (for instance, because mobile network is connected, but not able to transfer data [e.g. train tunnel] for 45 seconds) the sync process will fail softly and Android will retry again in a short time.
- Slow server: the socket timeout applies.
- Giant reply message: no timeout will occur, except when the server takes too long to calculate the reply (in this case: see “slow server”).
Don’t set the long timeout when adding an account, just on the sync calls.
Do you really think
DavHttpClient should have different timeouts for different actions? This would mean implementing a “mode”, for instance interactive mode and sync mode.
Most people won’t, so they won’t have any more issues than they do now, and DAVdroid will start working for me again.
I recommend to stay with DAVdroid 0.7.7 until the OwnCloud problem is fixed. Would that be a solution for you?