Debugging web sites and applications is a pain. Firebug has gone a long way to make it easier. With the release of the Opera 9.5 browser comes a new alternative for developers to not only debug apps withing the browser but, remotely as well as on mobile devices. To find out more about what Opera Draganfly is about, Schalk Neethling, Web Builder Zone Leader interviewed David Storey, Chief Web Opener and Consumer Product Management and Developer Relationship manager at Opera ASA. Below follows the interview.
Schalk Neethling: Thank you David for a taking the time out of your schedule for this interview. Before we go any further, please tell us a little more about yourself and the work you do over at Opera ASA.
David Storey: I was the first person at Opera that worked full time on "Open the Web". This is what we call our out reach efforts to get web sites to fix their issues with Opera and other standards compliant browsers. Often sites with deviate from the standards, or block Opera entirely, and our developers can't do any thing to fix those problems. That is where we come in. We work with some of the biggest sites in the world to help them when they're having problems supporting Opera.
From there I became a founding member of our Developer Relations team. This is the team that represents web developers in Opera. We do a lot of out reach to developers to make sure that we deliver what web developers need—that we fix bugs that are causing issues, add support for standards that developers need, developer tools, documentation and so on. We also do a lot of evangelism of web standards and are working on education to promote these standards to new developers and those that don't design with standards and accessibility in mind. A part of the effort was the recently released Web Standards Curriculum (WSC) http://www.opera.com/education/ that we produced to help students and developers learn web standards, rather than outdated table based techniques.
As well as this, I'm now acting as product manger for Opera Dragonfly, and represent our developer relations and consumer side of Opera when planning what goes into our Core rendering engine. The idea is that I can let the engineers know what web developers and designers are demanding, so that we know what to implement from their perspective.
Neethling: From what I have seen of Opera Dragonfly it is definitely going to excite a lot of developers but not a lot of developers currently know about Opera Dragonfly so, can you give us a quick overview of what Opera Dragonfly is?
Neethling: When one launches Opera Dragonfly, it takes some time to load and gives the impression that it is basically an Ajax based web-app loaded from the web. Am I correct in my assumption? If so, in which language is Opera Dragonfly written? Something similar to XUL in Firefox or is this based completely on existing web technologies?
There is no server side logic - it is purely client side, except the initial request to the Opera server to download the application. This is why Opera Dragonfly seems slow on start up, as it is actually downloading the application, not loading it. Once it is in persistent cache it should start up much faster. We will also optimise the code much more as we get closer to a final release.
Neethling: As the version of Opera Dragonfly that ships with Opera 9.5 is still in Alpha it is expected that there will be bugs that creep in here and there. I tried to access Dragonfly over a corporate network that has some proxy content blocking software installed and was unable to open Opera Dragonfly even after changing the proxy setting on the preferences dialog. Are you aware of this current limitation?
Storey: Proxy servers are an issue we are aware of, and it is something we have planned for in the architecture. Mobile networks sometimes run such proxies and will have similar issues. The solution is that Opera Dragonfly has a proxy which you will be able to download on your server, which allows it to communicate through the proxy. This hasn't been released yet. You can also download the Opera Dragonfly application on your machine and access it from there instead of the Opera server - this will not auto-update like it will if you use the regular Opera Dragonfly URL.
Neethling: With the previous question in mind, where would developers go to log and/or report bugs such as these while Opera Dragonfly is still in alpha and beta?
Storey: e have a feedback page at http://www.opera.com/products/dragonfly/feedback/ which explains how to give feedback and log bug reports.
Neethling: One of the most exciting features for me with regards to Opera Dragonfly is the remote debugging feature and the fact that it can not only be used to debug desktop browser based websites and apps, but also apps aimed at the mobile device market. Can you tell us a little more about this feature and how it works?
Storey: One of the most exciting features for me with regards to Opera Dragonfly is the remote debugging feature and the fact that it can not only be used to debug desktop browser based websites and apps, but also apps aimed at the mobile device market. Can you tell us a little more about this feature and how it works?
With Opera Dragonfly, a device that supports Scope can connect to the Opera Dragonfly client on another machine, such as Opera 9.5 on your desktop development machine. In Opera Dragonfly’s settings there is a “Remote debug” option. There you can change it to debug a remote device instead of the local instance, and set the port number that will be used to communicate with the device. Once this is enabled, Opera Dragonfly is ready to receive requests through the selected port, and devices can request to connect to it. In the device you want to debug, you can then go to <kbd>opera:debug</kbd> and enter the IP address of the machine you want to connect to, and the specified port number. You can try this out right now with two instances of Opera 9.5 on different machines.
Once connected, Opera Dragonfly will see the tabs, windows or widgets that are open on the remote device. It will behave exactly as if you were debugging a local page, except you are controlling the page on the device, not your local machine. You can edit the CSS in Opera Dragonfly for example, and you will see it update in real time on the remote device. That was quite a wow moment for us when we first saw in working.
Neethling: As Opera Dragonfly will be released as open source, which makes me for one smile, I am wondering, what is Opera's strategy behind this? Will developers be encouraged to provide enhancements to Opera Dragonfly and contribute this back to Opera? Is the idea that Opera Dragonfly will eventually become a community driven application with support and contributions provided by Opera?
Storey: At the current moment, Opera Dragonfly is only developed in-house. I think it is too early in the process to open it up completely for others to contribute, and Opera have very limited experience with Open Source development. Once the code, user interaction design and the road map is more mature, we can start thinking about allowing external contributors. We don't currently have an open bug tracking system for example. We've already had interest from developers on contributing to Opera Dragonfly, and even had a patch sent from a guy in Kazakhstan. We'll have to evaluate the situation, but it is something that I'm enthusiastic in doing. I don't see it as being fully community driven as it is an official Opera product, and we want to guide the project in the direction we think it should be going in, but taking input in from developers and the community is something we feel is important, after all, it needs to be a tool that is useful for real world web developers.
Neethling: ne of the new protocols that forms part of Opera Dragonfly and that will also be released as open source to the developer community is the Scope Protocol. From the little bit that I have read about it this is very exciting to me. Is this part of the strategy discussed above and, will Opera be opening up any additional such protocols in the near future that would be of interest to developers?
Storey: Scope is part of the Opera Core rendering engine, so we can't open source it. We will be publishing the specification though. It is a key part of Opera Dragonfly however, and we'd be interested in hearing from anyone that wants to implement it. Opera Dragonfly isn't the only thing that can use Scope though. We already have another product underway that will be using Scope that will be useful for web developers.
As for other protocols, I can't talk about any future plans around Opera technology, but we are working on some pretty interesting stuff, which I can't reveal. We've just released the File I/O API, which we are standardising at the W3C. Opera is a big believer in standards, so we try to standardise anything we do that we will be useful for others—the Widgets spec is another example of something we are standardising with the W3C.
Neethling: Can you expand a little on what exactly the Scope Protocol is and what developers will be able to do with it once it is released?
Storey: Scope is a protocol, which was originally developers for Opera Dragonfly, but which was designed to have uses beyond that. It is what we use to communicate between Opera Dragonfly and the browser rendering engine. This allows us to receive information about what the DOM looks like internally to the browser, which styles are applied, information about scripts, errors and so on. Messages are sent back and forth through Scope using XML or JSON. The JSON implementation is not complete yet, and should be finalised in Scope 4, along with supplying the information needed to do HTTP inspection.
Scope can be used to build tools that require knowledge about the inner workings of the page or scripts. Debuggers are the classic example, but you can imagine there are more uses. We are building a tool that adds support for Watir automated test cases in Opera for example. I'm looking forward to seeing what web development and QA tools are built, if any, by third parties.
Neethling: I also read about the different 'runtimes' that are exposed by each instance of the debugger and that for example when a page contains elements such as iFrame's etc. it runs/exposes it's own runtime. Can you give us a clearer overview of exactly what is meant by 'runtimes' in this scenario? Also, what then would be the effect of toggling the console to limit it's output to only the current runtime? What would the 'current runtime' in this case refer to?
Storey: A runtime is an internal browser terminology that slipped into early builds, and the language has been cleaned up a bit since. A runtime is basically an instance of something in the browser, such as DOM or script instances. One web page will usually be a single runtime, but with frames, you get multiple runtimes as the page is comprised of multiple documents. In Opera Dragonfly you can select any of the pages, tabs or widgets that are currently open, so the Scope protocol sends all of these runtimes, and allows the user to select which one they would like to debug.
The current runtimes is the runtime (or page/tab/whatever) that you are currently debugging. Limiting to only the current runtime will remove errors from other pages that you may have open.
Neethling: Now for the big question. With the Opera browser being in it's second beta cycle for the Kestrel release and Dragonfly only having entered Alpha, can we as developers expect a GA version of Dragonfly to accompany the GA release of Kestrel?
Storey: No, it will be still in alpha for the release of Kestrel. I'd expect version one will come out in the first half of next year, with quite regular updates throughout this year. We plan to release at least another alpha release this year, and a beta once we have an implementation of Scope 4 in the Opera rendering engine.
Neethling: Thank you for your time David. To close of, is there anything interesting you can let is in on with regards to other new and exiting solutions such as Opera Dragonfly that you guys have in the works?
Storey: Nothing I can announce yet, but we are always looking for ways we can serve the Web development community better. As I mentioned earlier, Scope will allow us to do some quite interesting things beyond just Opera Dragonfly. Not quite related to Opera Draognfly, we've just released a Web standards curriculum, as I briefly mentioned, to supply high quality learning materials to schools, universities and those wanting to learn the correct way to build Web sites using standards. This has been written by a number of industry experts, including people from Yahoo! This is something I'm excited about, as it is something I've wanted to do for a long time. It is easy to preach to the converted, but we must reach out to the source of the issue, and make sure people have access to good quality resources before they get taught or learn bad habits. Chris Mills did a great job putting this together.
Other than that, and the planned Watir support, we have some cool new technology we are working on, and we are advancing what we already have. Work is well underway on Core-2.2 version of the rendering engine, that will see a host of standards improvements, to keep us ahead of the chasing pack. This should be included in Peregrine, and be even faster than the current engine. I’m really looking forward to seeing the CSS improvements that it will bring. It should also be the first stable version of our core engine that passes the ACID3 test, or at least the standards part of the test.
Opera 9.5 Mobile is coming out very soon, including the same rendering engine as Opera 9.5. This should be the most standards compliant mobile browser on the market, and also supports Flash content. The user experience has improved a lot since Opera 8.x, and should really give Safari on iPhone a run for its money. I'd recommend readers that are locked into the build for iPhone mentality to take a look, and stop locking out other browsers, like was prevalent in the dark ages of the desktop Web.