ubuntu-phone team mailing list archive

[David Jordan <djordan2@xxxxxxxxxxx>]

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 <ian@xxxxxxxxxxxxx> 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     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>