Vivaldi Proposal; Open AR Browsing standard?
-
I am a big fan of Vivaldi and what its managed to achieve in a relatively short time. Like many, I am a old Opera-user and have lots of little things Id like to see, but personally all the "big stuff" is already covered and Vivaldi is now my main browser. What Id like to suggest though, is a direction Vivaldi should consider going into. Augmented Reality is on the cusp of being a fairly big thing, with numerous company's looking into making HMDs, and phones and tablets coming soon with various 3d-sensing/mapping features built it. Regardless of the individual success or failure of these devices, it seems a safe bet now mixing real camera feeds with virtual overlays will be with us for long run. Yet there isn't much hope of a protocol standard being fully adopted. There is, in theory, Wikitude's ARML 2.0 which is probably the closest, but not really adopted very well. If I want to put virtual annotation on a real location I can submit it to Layar or Wikitude. But to view it people would have to be using their exact bit of software, connecting via their severs. Even if I make the scene in ARML, it has to go via their servers for anyone to see it. [i]People on one system cant see the data from people on another. [/i] To my knowledge, you cant host your own data fully independently yet like how you can for the normal web - not without also hosting some sort of javascript application to view it, effectively putting a "browser in a browser" merely to let you host a 3d annotation. (I believe Layar lets you host data but still needs to go via them - you cant just goto a url in their app) This is like if every website needed its own webbrowser OR you were forced to use Facebook and nothing else - thats the state of AR right now. Every experience demands its own client software. What Id like to propose is Vivaldi work towards becoming the "browser for AR". That is, a browser that can interpret a bit of markup specifying a 3d file, then display that file overlaid onto a camera feed - all done natively in the browser. I appreciate its a lot of work, and might seem outside the scope, but I think Vivaldi is very well positioned to tackle this problem; 1. Vivaldi has shown massive developments and innovation in a short time. 2. I believe the Vivaldi team are interested in open standards. 3. Its a independent player in the market. Most of the main things calling themselves "AR Browsers" right now have been bought by larger players who tend not to have open standards as a priority. (Layar is now owned by Blipper, Metaio now owned by Apple) 4. While the needs of displaying something in real space seem quite different to rendering a webpage, theres no reason at all why many of the underline protocols cant be shared. Tcp/ip/http stuff at the very least. 5. It can be done somewhat gradually, with many of the inbetween steps also useful for normal webbrowser experiences. While full ARML 2.0 adoption would be nice, its not necessary to implement it all to have something useful. At one point I was on the W3C team discussing potential AR browsing standards, so I have a few insights into the basics needed. Sadly I don't think there will be any "official" standard till someone in the market first forms a defacto standard by being first. I hope Vivaldi becomes that first full browser to do so. I really believe its essential that if we are moving towards a "half virtual" world, then it should be one where anyone can create that data, anyone can host that data, and anyone should be able to write client software to view it. Without someone to push this though, its not going to happen. Thanks for listening, and I hope at least this prompts some thinking within the Vivaldi team -Thomas Wrobel
-
I don't see this happening until you see it in Chrome first – because at it's heart Vivaldi is just a web application running on top of something much akin to nw.js, electron or some other blink based web application wrapper. (I'd be curious which one, or is it an in-house fork?)
The "program" itself -- the menu, the tabs, the panels, the controls -- that's just a html, CSS and JS document being rendered in blink. The standalone blink "wrapper" they are using exposing the <webview>tag for use, which is kind of a jacked up on monster tires version of the <iframe>tag sitting in a nice little sandbox.<br /><br />So until blink supports it? Don't see it happening. REALLY they aren't making a browser ENGINE that would implement things like that, they are making a UI around an existing engine to add useful features to the front-end.<br /><br /><em>I'm still playing with doing this myself as I have some of my own ideas on how this should be done – one of which includes kicking react.js to the curb.</em></iframe></webview>
-