>From what I can tell, you want to run a copy of the database on multiple mini devices and have replication between them? If so, this isn't really a good use case for replication, and adds several unnecessary layers of complexity. So lets look at the end goal, you want multiple clients to have read/write access to the same data, with the constraint that the internet connection will be unreliable, but you still want the data to be accessible, and possibly, editable.
This can be easily achieved by implementing good development practises, similar to that of SPAs [1] or any "properly written" mobile application. The application would maintain its own database, for SPAs you'd probably use local storage [2] (assuming you didn't need to support ancient browsers), and for mobile apps you can use an embedded copy of SQLite3 [4] for relational structures, or couchbase mobile [3] for document store. These databases would sync using your "central" server, and your API design would depend on exactly what you are trying to do, for example for simple requirements you could use REST, but in others you may want to consider an RPC style, or you might want to have the best of both worlds. There are some frameworks out there which handle things like this, emberjs, angularjs etc, though personally I am yet to find a decent, simple and clean implementation of such a structure. To achieve this, you also have to consider conflict handling, for example if both users are offline and they edit a model, how would you handle the conflict? If you automatically handle merge conflicts then you also have to notify the affected users, and reflecting this in your UX is *hard*. The theory of distributed systems are actually quite simple, at least once you get past all the academic stuff, the hard part is exposing it to the user in a friendly way. You can get around many of these problems by disabling edits unless there is an internet connection, allowing only read access in the event of a connection drop out, then using model caching on the client side (along with a bulk retrieve request). However both approaches come with the same problem of delta changes, if a model changes then each app will need to be notified about this, ideally via a push mechanism. Designing an events system around this can be quite challenging, for even the most seasoned developers. If you have enough time/resources then it could be a fantastic learning experience for you, but if this is a quick/dirty project primarily lead by billable hours, then you probably don't want to follow this route. If someone sent me a spec like this, I'd say it would *easily* be 300+ hours work. Hope this helps, if I have misunderstood, let me know. Cal [1]: http://en.wikipedia.org/wiki/Single-page_application [2]: http://diveintohtml5.info/storage.html [3]: http://www.couchbase.com/nosql-databases/couchbase-mobile [4]: http://www.appcoda.com/sqlite-database-ios-app-tutorial/ On Sat, Feb 21, 2015 at 2:45 PM, Blazor <antom...@gmail.com> wrote: > Hi all, > > I was asked to design a new django app by a client whose needs are a little > bit context-specific. > > The purpose of this app is to introduce computer-assisted technologies in a > paper-based environment, in the e-Health domain. This client would like to > access a central server with a few mobile clients with the constraint of a > non-permanent internet connection, because the location of the mobile > clients is continuously changing and an internet connection might not always > be available. > > My current idea is based on a portable small server (a nettop, or even a > raspberry pi, as the computing power is not a problem for this app) with a > django app on it and a wireless access point for providing mobile clients > with an always-on portable server reachability. At the same time, I'd like > other clients around the world (a very little number, though) to still be > able to access a central remote version of the same service, so I'd still > deploy the same app (with its own DB replica) within a remote server. > > I hope I made my client's requirements clear: how would you manage the > synchronization between the two DBs, given that both DBs need a write access > and that the only relaxation of this constraint is that when the portable > server is on, the remote DB might work in a read-only mode (but this is not > required). > > Thanks in advance for any suggestions you'll provide me with. > B. > > -- > You received this message because you are subscribed to the Google Groups > "Django users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-users+unsubscr...@googlegroups.com. > To post to this group, send email to django-users@googlegroups.com. > Visit this group at http://groups.google.com/group/django-users. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/bb65e66c-4788-4010-9bfe-b8f20e41e5d1%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at http://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAHKQagF9tYpqx%3DSZdj-5KgvqPHBajbz-2C-%3DSQzctHhewPgAng%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
