Andrew Shorten @ Adobe

Microsoft made a lot of noise during the run-up to the launch of Silverlight 2 about ‘Deep Zoom’, a feature which lets users zoom into an image or collection of images using a control in a Silverlight application. There have been numerous comparisons between existing Flash-based options such as Zoomify and Zoomarama and disagreement over whether Microsoft’s solution adds anything new.

Recently a customer enquired about Scene7, Adobe’s Software-as-a-Service (SaaS) platform for delivering rich media content, and in particular how the zoom functionality compared with that provided by Silverlight. After talking with some of the guys on the Scene7 team and doing some additional research, it transpires that the way Scene7 approaches image zoom is completely different to that employed by other techniques, including Silverlight’s Deep Zoom.

Rather than manually creating a collection of optimised images from which all possible views of the zoomed image can be constructed, the Scene7 server dynamically creates and caches the images required from your hi-res master image (which can be upto 2Gb in size), which is uploaded to the Scene7 hosted service. Of course, for sites where image collections change infrequently, such as the Hardrock Cafe Memorabilia site, creating, uploading and managing a collection of images yourself is a relatively easy task; if however you’re running an e-commerce site and have thousands of products, each with different colour and fabric options, this would become a nightmare, especially if you wanted to offer both resized images (thumbnail, normal and detail) alongside the zoom-optimised image collection.

Scene7 has been particularly successful in the retail sector, where the customer is more focused on merchandising, selling and supplying products, rather than wanting to undertake a complex image management task that could undermine their ability to increase the range of products sold online. With the Scene7 service, images can be uploaded and deployed using a Flex-based management tool, with Flash and DHTML-based viewers available for integration with the customer’s website, so no additional plug-in is required by the end user to view the content.

I was pretty amazed to learn that Adobe serves over 1 billion images per day through our hosted Scene7 infrastructure – another example of how the Flash Platform scales to offer ‘enterprise’ solutions.

I should point out that Scene7 does a lot more than just zooming, there is some pretty cool stuff that lets you do dynamic image resizing, display multiple colour and swatches from a single image, spin/rotate product images and product personalisation.

More information on Scene7 can be found below:

• Online documentation
• Demos
• Getting started presentation
• 30 day trial account

For anyone involved or interested in distribution of media content over the Internet, understanding how the BBC’s iPlayer service has evolved, why certain decisions were made and what future directions are being explored makes for fascinating reading.

The European Broadcasting Union recently published an article entitled the “Evolution of the BBC iPlayer” which is based on a series of phone interviews with Anthony Rose, the Controller of the Vision & Media Group at the BBC. The interview covers a wide range of topics relating to the BBC iPlayer and it is great to see the BBC being so open about the technology, business decisions and supporting infrastructure that contribute to running a service which has delivered nearly 300 million content play-requests.

Some highlights from the interview are below, but I’d recommend that you download and read the interview and keep an eye on the BBC iPlayer blog where additional detail about the service is often published by the iPlayer team.

On Future BBC iPlayer developments: “Anthony Rose: The user will be able to download automatically a programme during the night. If you leave your computer on and if, for example, you watched Dr Who last week and the week before, it is likely that you will want to watch Dr Who next week. For ISPs, peak bandwidth is very expensive, but it is cheap during the night. We know that our top 20 programmes account for about 70 percent of all our bandwidth. In this way, most of our programmes could be delivered during the off-peak hours, downloaded and stored on the user’s local hard drive. Thus, peak bandwidth usage could be significantly reduced. This is really a mixed economy where the difference between streaming and downloading is getting blurred.”

On the decision to use the H.264 codec and playback performance: “AR: We have now found that H.264 does not use more CPU power for the configuration we have chosen, compared to the On2 VP6 codec. Rather, the contrary is true in full screen mode and, because we use hardware acceleration, it uses less CPU power. The answer is that, if you are not careful, H.264 is unplayable on low-end machines, but if you choose carefully, H.264 could be a pretty good user proposition.”

On using Digital Rights Management (DRM): “AR: For downloading, we have to DRM our files for two reasons. First, the rights holders expect that the content will be available in the UK only. Second, content must only be available for a limited amount of time, so it can be commercially exploited, as is the case with BBC Worldwide’s licensing of the Top Gear programme. Broadcasters in the USA who pay BBC Worldwide millions of pounds for broadcast rights would probably pay less if there was no DRM, as the content would be available elsewhere. This is the main reason why the rights holders demand DRM. In addition, it is a requirement of the BBC Trust (the BBC governing body) that files are only available for 30 days after download and seven days after being broadcast. So these are the reasons why we have to apply DRM to downloads.”

“AR: We have done a lot of due diligence and we have investigated all the
viable DRM solutions. We have met with companies that develop them and we looked at the technologies themselves and evaluated them. The reality is that, until quite recently, Microsoft was the only viable one. It is free, secure and approved by Hollywood labels and approved by rights holders. It is easy to put on servers and clients. The problem is, however, that it is Windows only.”

“AR: The good news however is that other companies like Adobe are developing cross-platform DRM products. Adobe AIR now has DRM available for the PC, Mac and Linux. We hope to have a crossplatform solution by the end of this year based on Adobe AIR and Adobe DRM.”

The beta version of the BBC iPlayer desktop application, using Adobe AIR and our DRM technology launched last week and has once again shown how the BBC are leading the way here – ITV, Channel 4, Sky and other broadcasters really need to learn from the BBC’s experiences and make their content available on platforms other than Windows.

I’ve recently been involved in contributing to and editing an Adobe whitepaper which is set to be published in the new year, entitled “The business benefits of rich Internet applications for enterprises”. Targeted primarily at a business, rather than technical, audience the whitepaper aims to explore the use of Rich Internet Applications within an enterprise environment and demonstrate how the Flash Platform can be used to deliver successful RIAs.

When talking about Flash, people often think about consumer-oriented web experiences, such as watching video on YouTube, exploring a micro-site for their favourite brand, editing photos and video on the web or being exposed to rich media advertising. The Flash Platform is used for all those types of experiences, but more recently, with the introduction of the Flex framework, expanded capabilities and performance with Flash Player and the arrival of Adobe AIR, the platform is being used by enterprise customers to build line of business applications.

Over the next couple of weeks I’ll blog extracts from the whitepaper here and provide additional thoughts/commentary on each topic – I’d be interested in your thoughts as we explore this, so please do comment on the articles or get in touch. Here’s a list of the topics that I plan on covering:

• What is an RIA?
• The role of an RIA in the enterprise
• RIA compared with existing technologies
• RIA development considerations and best practices
• Real-life enterprise RIAs

Let’s start with probably one of the hardest tasks – defining what exactly an RIA is. This is an often debated topic and one that we could spend a long time trying to get agreement on – for the whitepaper we defined RIAs as: “A new category of applications that bridge the client and the Internet cloud; solving the ‘rich versus reach’ conundrum, enabling Internet applications to be both rich in functionality and engaging to use, yet able to take full advantage of the Internet’s reach, connectivity, and deployment model”.

We went on to provide a slightly expanded description of what an RIA is (below), before moving on to the more interesting and relevant topic of why exactly they are important.

What is an RIA?

“A rich Internet application is the focal point of the convergence between desktop applications and browser-based clients. RIAs combine the strengths of both domains while liberating the user from their respective constraints.

A rich Internet application is a lightweight application with a subset of the functionality and feature set of a desktop application. The user interface may run in a web browser or some other application runtime. On first use RIAs are downloaded and accessed on demand. They may then be cached for future use or, in some scenarios, be deployed onto a device to provide access even when the user is disconnected from the network. Data may be cached locally and then synchronized with a remote server or may be kept on the server and retrieved when necessary. “

Why are RIAs important?

“Interactions with data and information stored in IT systems have evolved. The mobility of applications is a reality underpinned by the evolution of the Internet, the ubiquity of communication networks, and the explosive growth of portable devices and home entertainment systems. As bandwidth availability has grown and quality of service improved, more cost effective connectivity has increased adoption and reach. Your employees are no longer bound by their desktop systems. The affordability of improved bandwidth connections, combined with the rapid adoption of handheld devices and connected systems inside the home has led to a workforce and consumer audience that is more aware of the types of interactions open to them and expects more as a result. The boundaries between software applications and computers systems at work and those available to the home market are disappearing. Your workforce may be better connected and exposed to the flexibility and mobility of applications at home and on their personal handheld devices than they are at work.

The volume of structured and unstructured data is growing within organizations as well, even as it spreads to a wider range of computer-based systems. How your workforce gets access to that data in a seamless, more intuitive and flexible way will be a vital component to long-term success and productivity.

RIAs separate the application from the platform or device on which it is being used. This partitioning makes RIAs flexible and reduces the costly support associated with desktop applications. Small and lightweight, RIAs can be installed by the user quickly, easily, and when they are needed.

Unlike web and desktop applications that are constrained by their domain, RIAs can be used in either a connected or disconnected mode. As a result, the richness typically associated with large desktop applications can be applied to a lightweight application. This is something that web-based applications have struggled with substantially in the past, and marks a big step forward.
Underpinning RIAs are the tools that bring together design and development teams to realize the opportunity presented by combining a rich user interface (UI) with rich functionality.

RIAs represent an important value proposition to usability, flexibility, and the long-term effectiveness and efficiency of business applications and operations.”

Overtime, as RIAs become a part of the everyday computing experience, I think we’ll talk less about rich Internet applications and refer to them just as ‘applications’; today however, whether ‘rich’ defines the graphical user interface, the user experience or the quality and relevancy of the exposed data/services we need to remember that RIAs are not just about technology, they represent a significant shift in user expectation when compared with existing web or desktop applications.

In the next post we’ll consider the role of rich Internet applications within the enterprise environment.

The Essential Guide to Flash CS4 AIR Development, written by Marco Casario, was published today – Marco was kind enough to ask me to contribute a chapter and write the foreword for the book, so I thought I’d publish an excerpt from the chapter I wrote on Packaging, Distributing and Installing AIR Applications.

The book is available to order on Amazon and should be in bookstores now. If you’re already using Flash Professional to create web content then this book will help you get to grips with Adobe AIR and show you how to build and deploy cross-OS desktop applications.

More information and additional chapter excerpts can be found on Marco’s blog.

Excerpt: Digitally signing an AIR package

When viewing Flash or other content on the Web, the user is guaranteed a certain level of protection by the restrictions placed upon what the content can and can’t do when running within the confines of the browser sandbox. For example, a SWF running within Flash player can only write a limited amount of data to a very specific location on the user’s hard drive without direct user interaction.

The limited access to local system resources available to browser content means that users can browse the Web, consume content, and interact with applications without giving much regard to security, except in circumstances when they are explicitly providing personal or sensitive data over the internet.

Unlike browser-based applications, AIR applications have the same user privileges as native desktop applications, allowing them full access to the local file system. This means that a SWF running within the AIR runtime can read, write, and delete data anywhere on the local system, subject to the restrictions placed upon applications by the operating system.

To mitigate the risk to the user from installing an application, Adobe requires that AIR applications be signed by their publisher, so as to securely associate their identity with the application and to guarantee that after release, someone other than the publisher hasn’t amended the application code.

While it is possible to create your own digital certificate for use with AIR applications, such self-signed certificates don’t provide the user with the guarantee that you are who you say you are. In order to instill user confidence and guarantee that you are the publisher, it is necessary to obtain a digital certificate signed by a trusted third-party vendor. These trusted third parties, or CAs, validate your identity as a publisher and issue you with a certificate that you can use to sign your AIR application with.

Certificates and the AIR installation process

During the application installation process, the AIR runtime differentiates between applications that are self-signed and those that are signed using a certificate from a trusted third-party vendor.

Because self-signed applications represent a higher risk to the user, the installation dialogs highlight this increased risk by specifying the publisher as UNKNOWN and using red warning icons. The user will still be able to install the application, but by not using a trusted certificate you may find that users are wary of proceeding and choose to cancel the installation process.

By contrast, applications signed using a certificate from a trusted third party display the name of the application publisher and present a green “trusted” icon next to the publisher name. AIR applications have unrestricted access to the user’s system, so there is still some risk to the user—hence the yellow warning icon at the top of the dialog.

Another slight difference during the installation process is that applications signed with a certificate from a trusted third party will display the application icon on the second of the installation dialogs, whereas self-signed applications will not.

It is important to note that signing an application doesn’t make the application inherently trustworthy—the user can only trust the application if he trusts the publisher of the application. The AIR runtime provides the user with the opportunity to establish if an application has been signed using a certificate from a trusted third party, but the user must still make the ultimate decision as to whether to trust that publisher and install the application on their system.

Plan early for application signing

Right at the beginning of your project, as you’re scoping out the features for your application, you should allocate some time to consider how you’re going to sign your AIR application and whether you need to acquire a certificate.

There are a number of possible application-signing options that might be applicable to you, depending upon the type of application you are building and the organization that you are working for. In general, however, one of the following scenarios is likely to apply:

• You will need to acquire a new certificate from a CA to sign the AIR application
• Your organization already has a class 3–compatible certificate (suitable for user servers and software signing), and you plan to use that to sign the AIR application. More information on certificate types can be found at http://en.wikipedia.org/wiki/Public_key_certificate
• You are developing an application for a client and they will need to sign the application using an existing or a new certificate
• You are building an application that you are comfortable releasing with a self-signed certificate and don’t believe you need to acquire a certificate from a CA

If you need to acquire a certificate from a CA, you should allow a reasonable period of time to process the necessary paperwork, which may include providing documentation to a regional processing center so that the vendor can verify your organization’s identity. The next section discusses how to acquire a digital certificate.

If you know your organization has already published and signed a .NET, Cocoa, or Java application using a class 3, high-assurance code-signing certificate, then you should be able to use that certificate to sign your AIR application. You typically cannot use an SSL (Secure Sockets Layer) certificate to sign AIR files; a certificate must be marked for code signing to be suitable. You will want to allocate some time to test the certificate that you would like to use, and allow time to acquire a new certificate should the existing certificate prove to be unsuitable.

If you are developing an AIR application for a client, then the responsibility to procure the appropriate certificate and/or sign the application may fall to the client’s IT department. It is unlikely that the client will supply you with the private key for their certificate, and as such, they may insist you provide a build of the application that they sign. In this situation, you will need to supply them with an air intermediary (AIRI) file. This is an unsigned air package that cannot be installed, but that can be signed using the ADT (AIR developer tool) command-line tool supplied with the AIR SDK (software development kit).

Deploying an application with a self-signed certificate may be an option for you, even with the increased probability that some users will choose not to install the application. While it is possible to migrate from a self-signed certificate to a certificate issued by a CA at a later date, if from the outset you know that you will want to deploy a trusted application, then it is far simpler to release the initial application with a certificate from a CA.

Regardless of whether you need to acquire a new certificate, test an existing certificate, or produce an AIRI file to pass to your client to sign, you should allocate an appropriate amount of time for this as part of your overall project plan and not leave this task until you’ve finished the development of the application and are ready to deploy it.

Acquiring a digital certificate

While you can choose which CA you acquire your digital certificate from, thawte has worked with Adobe to provide a certificate service specifically for AIR application developers. At the time of writing, this is the easiest way to acquire a certificate to sign an AIR application, and so it’s the one you will use in this book.

The use of a thawte certificate is also convenient for end users installing your application; because the AIR runtime relies upon the operating system to establish whether a certificate can be trusted, it is necessary for the operating system to trust a chain of certificates linking the certificate to a known certification authority. Both Windows and Mac OS X operating systems come preinstalled with root certificates from thawte. Thus, your signed AIR application using a thawte certificate can be verified without requiring the user to install any additional root certificates on their machine.

To purchase an AIR Developer Certificate, the thawte website requires that you use the Mozilla Firefox browser, and that you purchase and retrieve the certificate on the same computer and browser. Once you have downloaded the certificate and private key successfully, you can export them from the browser keystore and use them elsewhere.

Follow these steps to purchase a certificate from thawte:

1. Visit the thawte website and select Products ➤ Code Signing Certificates from the navigation
2. Navigate to the purchase page by clicking the ‘Click here’ to buy link or button presented
3. From the list of available code-signing certificates, select Adobe AIR Developer Certificate, then click submit
4. Select whether you want to purchase a certificate for a one- or two-year period, and then enter the requested information about your organization, country, state/ province, city/town, and web server domain. It is important that the organization name be spelled correctly and in full, and that it represents the legal identity of the organization within the country in which it operates
5. Complete the remainder of the three-step enrolment process. thawte will then perform its identity verification process and may request that additional information be provided and/or that documents used to prove the organization’s identity be faxed to a local thawte office. The requested documents vary depending upon the type of organization and the country in which it operates, but may include articles of incorporation, VAT certificates, registrations of trade name, partnership papers, or certificates of formation
6. Once verification is complete, thawte will e-mail you instructions on how to retrieve the certificate. Using Firefox, navigate to the link provided by thawte, log in using the credentials specified during the enrolment process, and fetch the certificate
7. Your certificate will automatically be saved to the keystore within Firefox. It needs to be exported so that you can use it to sign your AIR application
8. Within Firefox, open the Preferences dialog from the File menu. Then click the Advanced icon and select the Encryption tab



9. To export your certificate, click the View Certificates button, select the Your Certificates tab, and then select the certificate from the list. Once selected, click the Backup button to export the certificate and private key in a p12 file to a suitable location on your computer

During the backup process, you will be required to protect your certificate with a password. You will need to use this password during the packaging process within Flash.

More information on Packaging, Distributing and Installing AIR Applications can be found in the book. Enjoy!

On the same day as Adobe announced that the final release of AIR 1.5 for Linux is available for download, the BBC have launched iPlayer desktop for Mac, Windows and Linux users, built on Adobe AIR.

BBC iPlayer desktop allows those in the UK to download their favourite BBC programmes and watch them when they are offline. The new desktop edition compliments the existing streaming service, which is available in the browser using Flash Player.

The application was built using the Flex 3 framework, runs on top of AIR 1.5 and makes use of the Flash Media Rights Management Server (FMRMS) to DRM-protect content which is downloaded to the user’s desktop.

The BBC iPlayer really demonstrates the power of the Flash Platform, enabling users to enjoy high quality video content on the web and on the desktop, across all major browsers and operating systems – congratulations to the BBC for launching so quickly after we delivered AIR 1.5 for Mac, Windows and Linux users.

If you’re in the UK you can download BBC iPlayer desktop here (note: you MUST be signed up as an iPlayer Labs user before the download option on iPlayer content will appear on the website).

For those outside the UK, there are some screen shots of the application below… I’m looking forward to playing with this some more tonight