File Access, Standard Video Embedding and 3D - An Interview With Charles McCathieNevile - Opera
Join the DZone community and get the full member experience.
Join For Free[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
Opinions expressed by DZone contributors are their own.
Comments