As Mike suggests, some of us our a little concerned about the dive
towards HTTP as a base's for a AR Protocol.
I'll just lay down my thinking along these lines here for now, but it
might be worthy of a separate conversations thread later.
Part of this is just to get it clear in my own head too, so excuse for
some of the baby-steps in my explanation.
--
HTTP and HTML are, as everyone here knows ancromins for "HyperText
Transfer Protocol" and "HyperText Markup Language"
Letting use jump from page to page pretty seemlessly.
We have built on these standards with stuff like php, allowing on-
demand server-side generation of pages.
And Javascript, client-side manipulation of pages at the Dom level.
But its still all bound by the concept of a page, which is defined
explictly by what the creator of the page sets.
The size of the page, the quantity of content and who contributes to
that page is all determained by the person
that wrote the HTML.
However with Augmented Reality there is no boundarys to the screen.
The positioning of elements stretchs to infinity in all directions.
What you see is dertermained by your camera view, and your devices
draw-distance.
The idea of having a boundary in AR just doesnt exist. There is no
"edges".
So how would you dertmain what AR data to put on the HTML page? A
whole worlds worth on a single page? Have seperate pages for each
city? town? Street?
Would clients need to load two pages if they were on the edge between
two locations?
Now imagine the contents of this AR View.
This content, just like a HTML page, has to be downloaded.
So what is the most efficianct method of loading the objects for this
view? How can the servers pass the data to the client with the least
overhead?
These are the questions any standard should be seaking to answer. And
I cant help but think using HTML/HTTP is the easy answer, but not
necessary the correct one.
For instance, theres no obvious equilivents to hyperlinks in AR Space.
Instead its the clients location that determains whats in its field of
view, and thus what it needs to see.
HTML, on the other hand, provides a fixed bundle of data.
Sure, you could use javascript in HTML to then stream other AR data
in, but it would be *that* information that would be the AR protocol,
not the initial (2D) page set up.
And if your defining a streaming protocol based on the users location,
then you wouldn't need javascript at all...any client-side code would
do.
--
So, to some up; maybe I'm wrong in my belief that WFP specifically
would make a suppiour protocol for geolocateing data. I dont want to
state boldly we have the answer, as it may yet prove unworkable.
But I certainly think we shouldn't just assume that building on HTML5/
HTTP is automaticaly a good choice.
Its the principles of openness that are important to keep as the Web
evolves, but we shouldn't be scared to format our data differently
when the end experience itself will be so different.
Thanks for listening,
Thomas Wrobel :)