I’ve been doing some research and thinking about database systems and the future direction I want for my applications.
I’ve been thinking about my home network which is wireless-based and how the network has a habit of dropping in and out. A lot of bigger companies have a rock-solid wired network but I bet that these days a number of smaller or home-based outfits have temperamental networks like mine.
The other thing I’ve been thinking about for the far-off future is web integration. I was approached to implement a web/ desktop application, i.e. use my app. as a frontend for a web-based DB. The idea was that a company would do work for clients but the clients would be able to remotely access the data. A browser-based interface wasn’t being called for: The clients would need to be able to work in a totally disconnected state. If the client updated the data locally, the data would need to be resynched centrally, so the synchronisation worked in both directions.
Doing some research on Google, I came across the concept of OCAs (Occasionally Connected Applications). One of the ideas behind OCAs is that the user works with a central DB server but if the connection to the server drops out, or is simply unavailable because the user is out and about in their car for example, data is stored locally on their PC. Any data stored locally on the user’s PC is then synced automatically with the central DB when the connection is next available. All this happens (as far as practically possible), without any “connection lost” errors popping up to annoy the user.
The concept of OCAs seemed very complicated BUT when I think how my home network is unreliable and my desire to enable web-working, I wonder whether any server-based setup should incorporate synchronisation and offline working aspects from day one, i.e. whether the concept of OCAs killed two birds with one stone.
Any experience or thoughts on this kind of application design?
{ 4 } Comments
>but I bet that these days a number of smaller or home-based outfits have temperamental networks like mine.
Ours has always been fine.
If we have a laptop near our tv equipment it can get a bit funny, but were aware of that.
The issue we have sometimes, is due to adsl disconnections, which might happen once a day.
ADO.Net is designed to work in a disconnected state, I’ve never tried it but, it uses XML to store data. Theres some example MS dotnet code, think theres some sort of work offline checkbox thing, like
browsers have in the example.
Looked quite easy to do.
I think the working offline aspect is FAIRLY easy to do.
It’s the merging of offline and online changes that’s more
tricky if someone has updated the DB while you were
disconnected.
In the past, if a write failed to the server, did the
systems you worked on flag up an error to the user? did
you retry a few times before showing the error?
I think ADO.Net will handle that too
I think you have to use the Microsoft Sync Framework
(MSF) with ADO.Net.
I’m getting pretty keen on SQLite. The only downside I
can see now is that there is no real support for MSF. I
wanted to see what you guys thought about the need for
on/offline support. I’ve not really considered it before but
I don’t want my customers losing data due to some
electrical problems.