ubuntu-phone team mailing list archive

[Callum Saunders <dancemeep@xxxxxxxxx>]

With regards to setting up sync, i was thinking that U1 would benefit from
having a 'Friends' feature, not only would it make sharing current U1
services easier it would help us make multiple Ubuntu devices 'social' with
each other, so that it would just be a case of sending a request to pair
the devices.

Would NFC be able to help quickly pair devices that aren't necessarily
'friends', similar to how Nintendo 3DS works? If i'm not mistaken it
exchanges profile information with people passing on the street. I'm not
saying that's how Ubuntu should work, but it sounds like an easy way to set
up sync services between 2 Ubuntu devices where NFC is available, without
having to scan a network (which might not necessarily be available) or be
'friends'.

Another way it could be taken is to be able to create groups or circles of
friends i.e. production team. So you can easily invite a predetermined
group of people for multi-device collaborative fun. I can see this being a
great benefit for business and production use.

On Mon, Nov 21, 2011 at 4:54 AM, David Jordan <djordan2@xxxxxxxxxxx> 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
>