File Access, Standard Video Embedding and 3D - An Interview With Charles McCathieNevile - Opera

[img_assist|nid=4802|title=|desc=|link=none|align=right|width=214|height=161]A short while back I read Charles McCathieNevile's post on Opera labs about not only support for <canvas> but taking canvas 3D. He mentioned File I/O that has been proposed to the W3C as well as support for the Ogg Theora format. Having read all of this, I had to know more so, I got together with Chaarls to find out more.

Schalk Neethling: Thank you for granting us this interview. Before we get into the meat of what this interview is about, please tell us a little about yourself and the work you do over at Opera.

Charles McCathieNevile: I am Opera's "Chief Standards Officer". That means I do a bunch of middle management stuff - looking at what standards groups and work we are involved in, who can represent us, and how we can find time to cover all the things we need to do. I came to Opera from W3C, where I worked for a half-dozen years (and a few weeks) on activities ranging from Accessibility to Semantic Web development, and my background is an Australian with a medieval history degree and a long history of student-type jobs. I also happened to play with computers and hypertext systems as a way of earning some money and learning some stuff, from the beginning of the 1980s until I accidentally got involved in explaining what I thought was wrong with a CSS2 working draft to my Mum - who pointed me towards W3C as the way to make the Web better.

Neethling: I read your post regarding some new and very exciting experimental features available in the latest labs release of Opera. For which platforms is this build available for?

McCathieNevile: The current build runs on Windows, Mac, and Unix. I have only tested it on the OLPC project's XO "$100" laptop and a MacBook, but you should be able to get it to move on Windows 95+, Mac OS X 10.2+, and a pretty wide range of Linux setups, at least.

Neethling: I first want to talk about the File I/O feature. I saw that it has been submitted to the W3C WebAPI working group as a possible standard that will be implemented cross browser. How is this process coming along?

McCathieNevile: Slowly. As with most discussions about standards, it begins with a question from people who didn't make it about why we want it, carries through discussion of whether this is the right approach (which is about where we are now), and goes around and around until we finally get something out - hopefully, something useful that significantly enhances what you can do.

Neethling: What exactly is the idea behind File I/O, or "file upload API" as it is also known? Can you also clarify what exactly is meant by 'widgets' in this context?

McCathieNevile: In this context, "Widgets" means what it means in the W3C "Widgets 1.0" spec - small web applications that can be installed and run locally. Opera has these on many platforms, Apple dashboard is for managing widgets, and there are various other platforms (we hope that W3C's work will lead to a single standard so developers aren't spending most of their time trying to find out how to add another platform, but spend their time thinking about how to improve what their widget offers). An example is the opera widget "Artist's Sketchbook" - http://widgets.opera.com/widget/4647/ - which is a graphic editor, and resorts to all sorts of tricks and kludges ust so the user can load and save their own images. In the experimental build we released, File I/O is only enabled in Widgets. This is a temporary measure, and is related to security as I will explain later.

File upload API is conceptually pretty simple. Currently, in HTML, you can upload a single file, that you choose from your computer, to a website. This only works in HTML - if you build some other kind of standards-based application, perhaps using SVG for your interface and javascript for some advanced functionality, it isn't available. And it can only load one file at a time. OK for selecting your personal photo on a blog, but a pain for putting photos on the Web. Also, an application you get from the Web cannot actually read a file - so you can't make a simple editor or a powerful image editor that is useful on your own file system - it all has to be stored by someone on their web server.

The Web Applications working group (whose job is to produce standards so we can have better Web Applications) has a work item to improve this. There are a couple of different simple specification proposals that allow javascript programs to request a file for upload. It is important that the file be selected by the user, and they know that they are handing it over to the program (and therefore the web at large), rather than letting any web author start digging around your file system. That is a pretty basic security principle.

With File I/O we have taken this security principle, and used it and what we know about what applications try to do, to offer much more functionality to applications while protecting the user. Roughly, File I/O means that instead of naming a single file that an application can send to the server it came from, the user can also decide to give the application a protected, secured piece of their file system to work on. That might be a new directory you create, to store the images you work on or the documents you edit through some widget. But you can also choose to let the application have access to somewhere you already have files. This means that you can make a widget which lets you tag images, and give it access to a particular collection of photos you choose. Or have a widget that plays tracks from your local music collection.

Basically, it is a fundamental step in letting Web Applications be produced to do the things that we used to rely on shrink-wrap software to do, and currently only do through some uncomfortable shifting of files combined with handing themn over to someone else's server.

Neethling: It is certainly good news that the the royalty-free Ogg Theora video format seems to have been accepted as the standard on which in browser video support will be implemented. However, beyond a proposed <video> tag in HTML5 and the need forplugins to enjoy video going away, there is certainly much more to this. I have read about using video in SVG, creating controls for your player and even filters and reflection by simply using CSS, SVG and JavaScript. Please give us the low down on what all this holds in store for web developers.

McCathieNevile: The low down is having a simple way to add video to your content. This simple:

<video controls="controls" src="some.ogg">In the current design,
  the video itself is made to be accessible.</video>

But if you want more, you can indeed do more. SVG actually already has all of this (including the ability to add cool effects, use the videos as draggable obects, etc - see the links from my original article for a few demos that show some of the power. The only thing that has been missing is a standard format that you could use for your video. Unfortunately there has been a lot of FUD cast around (for example by some patent holders) about the patent risks associated with using free video standards - especially Ogg/Theora which is believed to be unencumbered by any enforceable patent.

We are pleased to see that Firefox has now joined us in implementing Ogg/Theora as a video format, and we hope that this will lead to its adoption as an initial format that anyone can implement and use without having to pay license fees to some collection agency before they are allowed to start doing the real work. Otherwise we are afraid that the current situation, where you pay one set of fees when you buy a phone, to have one set of video software, and a different set of formats on your desktop, will mean that video is always a complicated thing on the Web, only really available at the rich end of town rather than being able to enrich everyone's life equally.

So, if Web developers start supporting the use of Ogg/Theora (or indeed, another *free* format such as the BBC's DIRAC), they can look forward to simple, ubiquitous video on the web that just works, and that offers lots of possibliilties for expressing creativity and showing things with moving pictures(!) wherever people use the Web, on whatever device. More importantly to software for working with it being available both as commercial offerings and as open source projects, with all the rich variety that you currently find in, for example, Web Browsers.

Neethling: I think there are very few web developers that has played around with the <canvas> element. And now you are introducing 3D Canvas. Before we get into the details of the 3D Canvas, I read that this is a sort of joint venture between Opera and Mozilla. Is this true? Is this a completely collaborate effort between the two companies or mainly idea sharing?

McCathieNevile: At the moment it would probably be truer to say that we are both working in this area. 3D canvas is still pretty experimental stuff, and we are looking at different ideas right down to the level of pretty fundamental design choices that will determine things like whether we go for speed over portability, or vice versa. Or more realistically, exactly where we decide to make the inevitable compromises to ensure that we get an overall best outcome.

Neethling: The 3D Canvas is a brave new world and indeed everything about the 3D Canvas cannot be covered in this interview but, please give us a run down of the Opera 3d-context, what's possible, what's not and what might be in the future.

McCathieNevile: Well, it's not just too big a topic for a short interview, but it is not something I am a real expert on. (You might want to talk to one of our people who is...). But what I know is that in the current build we have it isn't implemented for all platforms - in particular it relies on some stuff that my OLPC doesn't have, but we have designed our 3D context around the idea that we can implement it ourselves on such platforms. Remember, this aspect of the build is a really very experimental preview and we haven't done a huge amount of work on it yet.

In the current build, you can basically create a bunch of 3D objects, and you can put pictures on them to give them a texture. You can then make them appear, move around, and you can (most of the time - this is experimental!) find out if they bump into each other as they move. This is enough to do some nice stuff already, and there are demos like a 3D snake game, or a simple cube that shows how you can put different images onto the faces of an object, and then have it start moving around.

The future is a huge and amazing place, and somewhat unpredictable. But a few things are pretty obvious. Being able to do lighting effects is something that is pretty important to optimise in lots of 3D use cases. And of course, being able to make this work on many many platforms - phones and televisions as well as high-end laptops - is something that has to happen for this to become part of the Web.

Neethling: The web, and specifically the browser, is certainly becoming an exciting and fast paced environment and Opera seems to be one of the front runners. Thank you for taking the time to do this interview. All the best for you and Opera.

McCathieNevile: Thank you very much. I hope you and your readers enjoy playing around with the test build and the demos. Remember that it's experimental and back up before using it. And please don't tell anyone that since I installed it on my machine and started playing with it, it has become my primary build, and this email was written using that build...

In the mean time, we will keep working to bring you more better browser, that keeps you ahead. All the best cheers