Yes, for some applications we might want to treat the TV as the "main" couchdb in that we would setup the *two-way* sync between every device as a pairing between the TV and a mobile device. However, it could just as easily be paired with some desktop or server as a master with the TV and all devices syncing to that, or even a chain where one device syncs with a second, the second with a third and the third with a fourth. In any case the changes would propagate down the line. The sync network topology could be anything, but for most TV-centric things treating the TV as the primary that everything else syncs with. There might be cases where we might want another local machine or a remote server as master for one thing or another, but the principle is the same, whatever the master is. David Jordan
On Sun, Nov 20, 2011 at 10:57 PM, Ian Nicholson <[email protected]> wrote: > On 11/20/2011 10:54 PM, David Jordan wrote: > > I think using a real-time synchronized database is probably the best > > way to provide these sorts of seamless multiscreen applications. > > The way it works in Novacut, each system keeps a synchronized copy of > > the database. Each application using the database communicates only > > through changes in the database, so when the user makes a change with > > one client, the client makes the appropriate change in the database. > > These changes are then replicated to any remote databases in > > real-time. The changes feed is sent to each application, which update > > themselves based on the new changes. > > This actually has a couple of benefits. If you implement this sort of > > architecture, you essentially get real-time collaboration almost for > > free. It also makes it much easier to make sure the backend and > > frontend components are loosely coupled and enforces a consistent data > > model, which makes creating stable, robust applications much easier. > > Now the database behind this needs to have properties fairly similar > > to couchdb: It needs to be document oriented, and in terms of sync it > > should probably work fairly similarly to how couchdb _rev works. > > In terms of how the user interacts with applications on the TV, having > > a set of documents in the database for each state you want to > > control. Then have a client on the tablet or phone that makes changes > > to the document. In terms of what the user sees, they would press > > some buttons in a GUI on their tablet or phone and the client on the > > TV would respond. You might setup general controls for the system the > > same way. > > Setting up Synchronization: > > Initially you would need some way to pair devices, which would amount > > to finding the remote device, handling authorization as needed, and > > setting up synchronization. > > We could use something like Avahi to make discovery easy on the local > > network. Some way to control access to the device owner is probably a > > good idea. Something like a captcha or qrcode displayed on the screen > > during pairing with an optional password to allow the device access to > > the database. At this point the two databases should be able to > > synchronize any time they can see each other. Synchronization over > > the local network is great for low-latency input and for letting > > friends pair their devices with your system while they're over. One > > could perform similar synchronization via a service like Ubuntu One if > > it supported real-time sync. > > David Jordan > So basically, the TV would act as the "main" couchdb server and the > tablets/phones would synchronize their local copies of the couchdb > server with the tv?(I apologize if my terms are wrong here) > > -- > Mailing list: https://launchpad.net/~ubuntu-phone > Post to : [email protected] > Unsubscribe : https://launchpad.net/~ubuntu-phone > More help : https://help.launchpad.net/ListHelp >
-- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
