Geolocation over WFP

20
Geolocation over WFP or..Selectively sharing real-time editable geolocated content over a federated system. or how I learned to stop worrying about wave.google's "bomb" and love the server tech behind it.

Transcript of Geolocation over WFP

Page 1: Geolocation over WFP

Geolocation over WFP or..Selectively sharing real-time editable

geolocated content over a federated system.

or how I learned to stop worrying about wave.google's "bomb" and love the server tech behind it.

Page 2: Geolocation over WFP

Geolocation over IRC?

IRC is...

Real-time

...a open protocol

… real-time

...big; Many servers each with many channels

… capable of letting anyone create their own channel and share information

with whomever they want

.. able to run bots

Page 3: Geolocation over WFP

Geolocation over IRC

IRC allows Selective sharing of geolocated content in real-time

Page 4: Geolocation over WFP

Selective sharing of geolocated content in realtime. Implementation over IRC was simple in principle too.

(from "everything everywhere", a paper explaining how simple AR content could be shared via IRC or IRC-like networks)

Page 5: Geolocation over WFP

Selective sharing of geolocated content in real-time. Implementation over IRC was simple in principle too;

(It worked by simply broadcasting a xml string geolocating a mesh to a channel of the user's creation.)

Page 6: Geolocation over WFP
Page 7: Geolocation over WFP

Persistence and WFP WFP at a low level; * The Wave Federation Protocol is server-to-server protocol - an extension to XMPP * Its most significant feature is Operational Transformation * OT allows a shared xml document to be kept in perfect sync, despite multiple simultaneous editors on multiple clients. Clients are only pushed the changes, not the whole document. * These clients could even be connected via separate servers, yet everyone sees each others updates within a few seconds, and always the end result is identical, regardless of the order the end client receives the operations in. * This is not trivial! Operational Transformation is a very significant ability and useful for any real-time collaboration.

Page 8: Geolocation over WFP

Persistance and WFP WFP at a high level; * Like IRC, WFP lets anyone publish and selectively share a real-time streams of information. * Like IRC, its also open; anyone can write a client or server and join the federation. No company is in charge of the network or acts as a global hub. * Unlike IRC,however, the information exchanged can be persistent, and has much more modern security features. * Overall, this allows anyone to publish information and allow anyone they wish to see...or edit...it at any time.

Page 9: Geolocation over WFP

IRC is...

Real-time

...a open protocol

… real-time

...big; Many servers each with many channels

… capable of letting anyone create their own channel and share information

with whomever they want

.. able to run bots

Page 10: Geolocation over WFP

Wave is...

...an open protocol

… real-time

Many servers can each contain many waves

on different topics

… capable of letting anyone create their own wave and share information with whomever they want... like

an IRC channel

Geolocation over WFP

Persistant

.. able to run bots

Page 11: Geolocation over WFP

WFP and geolocation

* WFP can be used for many things- the server protocol itself is just about the synchronized federated exchange of bundles of information without any preconception of what they are used for. * These bundles of information, wavelets, are pushed to clients via a websocket connection automatically as soon as they are updated on the server....and only the updated information is exchanged. * We believe this property especially is good for AR, as it lets the end user receive instant updates without the client wasting too much bandwidth, or the publisher needing to do anything special.

Page 12: Geolocation over WFP

WFP and ARWave

XMPP

Wave

ARWave

Wave Server

Page 13: Geolocation over WFP
Page 14: Geolocation over WFP

WFP and geolocation

* At the moment with our proof of concept clients we are just using a simple hash-seperate string of key value pairs to position objects. For instance, to position a 3ds file at a location we just used; #ARWAVE#51.558876801318085#5.078215599060059#0#http://www.atresica.nl/images/largebuilding/building.OBJ#application/x-obj# * This string was stored in a wavelet. * We then sent this wavelet to a Apache-wave server via a websocket connection. * The Apache server then automatically pushes it out to any other users invited to that wave - using websockets if they are users with accounts on that server, via WFP to other servers if users on other servers have been invited to that wave. (a wave being nothing more then a bundle of wavelets users can subscribe too)

Page 15: Geolocation over WFP

* Using the techniques outlined, we managed to move 3d objects in real-time using data exchanged between a standalone Android client and a web-based Google-map client; * The lag time between updates was just under 2 seconds (with rather unoptimised clients)

Page 16: Geolocation over WFP

* Our hash strings are just a place holder. What is important is the key/value pairs used to link the real and virtual worlds together For example, we could use the following keys:

* We could link to any media standard (3d, sound, linked data) * Hopefully we can agree on the key/value pair we're using! * Don't like these ones? Let's make up our minds so we can move on ;-)

Actually, wavelets can store key/value pairs natively as 'annotations'

Key Value

Data darkflame.co.uk/mesh/church/church.kml

Lat 49.5000123

Long 2.4000243

Alt 25m

... ...

Key Value

Data “Hello world!”

ParentURI atresica.nl/people/is_me.png

Y 0.5m

... ... style atresica.nl/make-up/

pretty.css

A 3d mesh A billboard

Page 17: Geolocation over WFP

....that said, we do believe a few principles we use for arwave would benefit any exchange of geolocation data; * The data linking virtual data to the real world should be as small as possible, allowing clients to search over a very large number of potential POIs and select what to display. * Thus we think 3D meshes should be remotely linked, and not embedded with the locational data itself. * We believe binary 3d mesh formats should be considered, as they can be smaller and quicker loading on mobiles.

Page 18: Geolocation over WFP

* An exception to remote linking should possibly be basic billboards, as the data is likely to be very small for these. Reducing remote server calls for small bundles of data tends to be more server efficient Take a look at how Google stores there logo file for an example of this optimisation;

* So a balance between inlined data (small) and remotely linked data (large files) will be best at reducing bandwidth use and thus server costs.

Page 19: Geolocation over WFP

Final thoughts - WFP is still a very in-development protocol with the Apache-foundation leading the way with its WiaB server. - While installing a wave server is fairly easy for any company or individual to do, the codebase for clients and the documentation surrounding it leaves a lot to be desired. - In short, working with wave at the moment is hard. - But, despite this, we believe selective sharing a big potential use of AR and the WFP is the best way we see of delivering this while not requiring all the users to be on the same company's server.

Page 20: Geolocation over WFP

arwave.org arwave is currently just a set of passionate coders working in their free time. The arwave team is still looking for sponsorship, or more coders to help develop it into a mature, easy-to-implement system. We plan to produce a set of open, well documented, set of APIs and code examples to make it easy for anyone to implement reading/writing to wave servers from their apps. We hope this, together with general standards for both data linking and data content, will help foster numerous ar browsers and applications, all sharing augmentations as public...or as private...as the end users wish.