Page Comparison

Saptarshi,
 
I think the best available solution to the syncing issue (at least for data in JASON form) is through that built into CouchDB. Sync and replication are core features and, as with RabbitMQ, CouchDb is written in Erlang and OTC for extreme fault-tolerance.  CouchD incorporates collision detection and provides mechanisms for conflict resolution. It is designed to achieve "eventual constancy" and emits change events, useful for coordinating other processes.
 
Erlang and OTC were developed in the early 1990s (and later open sourced) by Ericsson to maage its global telecom business.  Using them, Ericsson built an outstanding reputation for high availability service. The BBC and Ubuntu have used CouchDB in large scale, distributed environments for a few years.
CouchDB is a JASON document store that incorporates a web server and a JavaScript engine.  Because it stores web apps as JSON docs, and can execute and replicate (hence, deploy and update) them, CouchDB is also an applications server.  These so-call "couchapps" should have all we require for building and deploying client UIs.
-- Greg
Do no harm, waste no fortune.
On Oct 1, 2011, at 1:49 PM, Saptarshi Purkayastha <sunbiz@gmail.com> wrote:
One of the main challenges in a fully decoupled system is that the underlying data might b updated at different locations and data very often might b out of sync. In RESTful world, the concept of ETags proves useful in this respect and we specifically added support for ETags in the OpenMRS webservices.rest module.
Im also very keen otherwise if syncing can b managed without complexities and html5 offline storage is useful in this regard.
More on conf calls. Please do share the diagram that u describe during the weekly calls
Sent from my phone
-- Saptarshi Purkayastha
On 01-Oct-2011 10:08 PM, "Gregory Kelleher" <greg@kelleher.cc> wrote:
Hi Saptarshi,
Thank you for the clarification.  I not only agree with the "loosely-coupled" approach", I'd like to recommend consideration of a more complete de-coupling. 
By moving the processing to the client-side to the maximum extent possible I believe that you could improve fault-tolerance (using HTML5 off-line processing), improve responsiveness, reduce bandwidth, and lower the skill requirements  for development and support.  By using web sockets and robust message queues (via RabbitMQ, in particular), you can enable light-weight concurrent systems for QA, administration and public health through subscriptions to appropriate queues.
I look forward to discussing these claims but it might help to start with an overview of the system.  Judy is helping me describe (and improve) a diagram and description.  We may have a draft ready to share this weekend.
-- Greg
Do no harm, waste no fortune.
Begin forwarded message:
Saptarshi,
I neglected to comment on your first paragraph, with which I am in full agreement.  I too have been working on a variety of devices, looking for ways of implementing "write once, use everywhere" that was an unfulfilled promise of the early web.  With the browser wars behind us and the good work of WHATWG, it looks achievable.
-- Greg
Do no harm, waste no fortune.
On Oct 1, 2011, at 11:12 AM, Saptarshi Purkayastha <sunbiz@gmail.com> wrote:
Hi Greg,
The idea that we are promoting in our efforts is to have simple, lightweight and intuitive user experience that is usable of a variety of displays. These could be touch-based or mouse+keyboard style input and small to large, output displays. This we hope to do through HTML5 elements and implement the intuitiveness and cross-platformness through JQuery. Most, if not all, processing will happen on the server-side through a REST interfaces and JSON objects will be understood by the client-application (in the lack of a good name) 
By modules, we mean the server-side as well as client-side webpages. The server-side modules are OpenMRS modules (over 100+ modules already provide different types of functionality). We have to pick and choose the ones we need, add some REST annotations to expose the objects as JSON and build the webpages and user-experiences. We are still in the process of creating UX guidelines that are common across all modules, so that the modules look coherent... and we have extremely talented UX designers leading that effort and we hope to have that completed soon.
Some functionality, like billing, pharmacy, in-patient admission might require additional tables, API and RESTful behavior. These will be implemented as OpenMRS modules, but again the UX will be webpages+jquery, outside of OpenMRS modules, and part of the client-application.
Hope that answers your doubts about the super-structure. We will have a more in-depth discussion (on our weekly calls) on this as we have the 1st-pass of the UX designs available and how we can share many UI components between one-another. I'd like more and more people to debate and brainstorm the advantages/disadvantages of this loose-coupled approach.
---
Regards,
Saptarshi PURKAYASTHA
My Tech Blog:  http://sunnytalkstech/http://sunnytalkstech