El disseny d’interfícies no és cosa de molts

Article boníssim sobre el disseny d’interfícies i l’impacte de qualsevol decisió de disseny sobre l’usabilitat.

Ens parla dels compromisos inherents en qualsevol decisió de disseny. També del mal que pot fer el disseny d’aplicacions en un comité on tothom hi diu la seva. També planteja la idea d’objectivar les decisions que es prenguin i construïr si cal una taula amb les avantatges i les consequències de cadascuna de les decisions.

Lectura obligada si ens dediquem al disseny i conceptualització de productes. Bookmark afegit.

Posted in Catalan, Management, UXD | Tagged , , | Leave a comment

Components on the server (5): better Unit Testing

In this installment of the OSGi series, we add more complete Unit Testing support in the project. We also establish that some behaviour of the Servlet Bridge may not be what we want and then provide a way to customize it.

Continue reading

Posted in Computing, Java | Tagged , , , , , | 3 Comments

Automàticament Monster Lego

Fent unes reescoltes he trobat aquest genial remake del clàssic ‘Monster’ dels galesos The Automatic. Genial!

Posted in Catalan, Entertainment, Music | Tagged , , | Leave a comment

Components on the server (4): adding Tomcat support

In this post, we examine what is needed to deploy OSGi in a regular Servlet Container using the Equinox Servlet Bridge. We also use the Servlet Bridge to deploy our OSGi cache using Tomcat and wrap it up all together in a standalone WAR archive.

Please read the previous installments to get up to speed and see the source used in this post.

Firstly, we need to setup some kind of project to hold all that is going in the WAR archive. This can be done using the WTP (Web Tools Project) or just as a regular project.

In this case we do it using a plain-vanilla resource project but feel free to use WTP as the basics are the same.

So firstly we create a resources project to hold the stuff, named ‘com.calidos.dani.osgi.cache.package’ for instance.
Secondly, we create the folder structure we need to hold all the files that need to reside in the final WAR webapp, so we create a WEB-INF folder to hold all the classes, libraries metadata and configuration.

We also know we need a web.xml file to define all the servlets this webapp declares. This is where the Equinox Servlet Bridge kicks in. It provides a Servlet that loads up the environment as well as forwards any HTTP requests onto our OSGi-managed Servlet instances.

We check the Equinox in a servlet container article and learn what the bridge Servlet is called, what parameters it can take and any other web.xml details we need.

For instance, we declare that the webapp service class is our BridgeServlet class:


We also add two parameters (more information and additional options can be found on the FrameworkLauncher servlet bridge class and the Equinox documentation).

Next, we need this special servlet itself. I prefer to check out the servlet from CVS and compile it myself but you can also find it here (from the the Latest Release pick up the org.eclipse.equinox.servletbridge jar). In the case of using the source, the CVS connection data is the following:

Method: pserver
User: anonymous
Host: dev.eclipse.org
Repository path: /cvsroot/rt
CVS Module: org.eclipse.equinox/server-side/bundles/org.eclipse.equinox.servletbridge

Once we import the project into Eclipse it looks like this:

Servlet bridge project

As we can see, there are just three classes which compose the servlet, a special classloader and finally a class that launches OSGi.

If we import the project into our workspace, we have compiled classes in the bin/ folder of the project but we really want them neatly packaged as a jar file. Therefore, we right-click on the project to export as a JAR java package:

Servlet bridge JAR export

We take this JAR archive and save it in our package project WEB-INF/lib folder. We also check the composition of the file to make sure it includes all the classes we need.

This takes care of the plain webapp side of things so we move onto actually loading OSGi and what configuration it needs.

As mandated by Equinox we add a launch.ini file to clear and possibly override System properties (please see the source for details on that).

We then create an eclipse folder, which the servlet bridge expects to find the OSGi platform jar and any bundles (including ours).

We select all our project bundles, right-click and select the ‘Export…:Deployable plug-ins and fragments’ option.

This leaves us with a list of bundles that compose our custom code:


Good, as we know, there are some standard and some special bundle dependencies we need as well. Let’s go through them by groups. We get a bunch of basic OSGi bundles we should include in most projects:


There are several options to obtain these bundles:

For expediency, we can go to our Eclipse installation folder and look for them in the ‘plugins’ subfolder. We then copy them into our package ‘plugins’ folder and there you go.

The second option is to get them from the Equinox distribution.

Another option is to the prepackaged servlet bridge feature which can be picked from CVS as well:

Method: pserver
User: anonymous
Host: dev.eclipse.org
Repository path: /cvsroot/rt
CVS Module: org.eclipse.equinox/server-side/features/org.eclipse.equinox.servletbridge.feature

Once that is loaded onto our workspace, we open the feature.xml and select the ‘Export Wizard’ form the ‘Exporting’ section. This lets us export these minimum bundles and generate both the deployment ‘feature.xml’ file as well as the bundle listing (even though the wizard actually takes them from our Eclipse platform).

We also have some more dependencies related to doing HTTP and the logging platform:


These can also be obtained from the Eclipse plugins folder or Equinox distribution folder. One should note that modifying the feature.xml taken from the Eclipse CVS repository, adding any required plugins there and then running the Export Wizard.

Finally, we have two dependencies we need to pay special attention to:


In the first case, it’s a special minimal bundle that hooks the plain webapp servlet bridge with the OSGi ‘org.eclipse.equinox.http.servlet’ standard component which publishes a servlet service onto the OSGi platform.

This are the details to get it from CVS:

Method: pserver
User: anonymous
Host: dev.eclipse.org
Repository path: /cvsroot/rt
CVS Module: org.eclipse.equinox/server-side/bundles/org.eclipse.equinox.http.servletbridge

We export it as a deployable plug-in and add it to the mix. We can also download it from the Equinox distribution site as well.

In the second case, this bundle contains the basic servlet classes and interfaces and I have found problems of class signatures when using 2.5 along with the servlet bridge so unless all is compiled against 2.5 the safest bet is to go with 2.4.

(Check http://www.eclipse.org/equinox/documents/quickstart.php for more info).

Next, Equinox requires an XML file to define some metadata about the loaded bundles and make our configuration easier. The file sits in a folder called ‘features’ plus a subfolder with a reverse DNS name and is called feature.xml.

The structure is quite simple (though it can be created using the Eclipse Feature Export Wizard) and mainly holds a list of plugins, their version data and some more fields:

We complete the list with all our bundles, fully knowing that we can extend our environment on the fly once it’s loaded if we need it.

Next, we create the config.ini file which really tells equinox which of the bundles stated in the feature file to start, at which start level and lets us add even more bundles (though we need to specify where the actual file is located and the full filename in that case). It also lets us configure the environment pretty thoroughly.

The resulting config.ini file looks like this:

#Eclipse Runtime Configuration File
osgi.bundles=org.eclipse.equinox.common@1:start, org.apache.log4j@start, org.eclipse.osgi.util@start, org.eclipse.osgi.services@start, org.eclipse.equinox.http.servlet@start, \
org.eclipse.equinox.servletbridge.extensionbundle, \
org.eclipse.equinox.http.servletbridge@start, \
javax.servlet@start, org.eclipse.equinox.registry@start, org.eclipse.equinox.http.registry@start, org.eclipse.equinox.servletbridge.extensionbundle \
org.eclipse.equinox.http.servlet@start, org.eclipse.equinox.common@start, com.calidos.dani.osgi.cache.log4jconfig, \
com.calidos.dani.osgi.cache.provider.memcached@3:start, com.calidos.dani.osgi.cache.provider.memory, com.calidos.dani.osgi.cache.controller@4:start, \


We decide not to start the in memory bundle as it only works reliably in a single instance deployment scenario. Otherwise, in a multiple server setup the in-memory cache data would become inconsistent.

Also, be sure to check the Equinox quickstart guide and documentation for more information.

Once all is is done, the project looks like this:

Finished package project

Time to right-click on the project and select ‘Export:Archive file’ to save it in zip format and rename it to .war. Ready to deploy! Remember to access it using the URL //cache/. In web.xml the ‘-console 6666’ parameter means that doing a telnet on port 6666 of the machine initiates a session within the OSGi console. WARNING: there is absolutely NO SECURITY so disable, firewall or ACL that port NOW.

As usual, here you can find the source and the completed WAR though they are one and the same.

Posted in Computing, Java | Tagged , , , , | Leave a comment

Idea: ens treiem de Google a veure que passa

La idea més absurda que he sentit últimament, de mans de News Corp i Microsoft. Arribar a un acord d’exclusivitat perque el cercador de MS Bing sigui l’únic que indexa les seves notícies.

Sense comentaris.

Posted in Business, Catalan, Management, Media | Tagged , , , , , | Leave a comment

Components on the server (3): adding a HTTP frontend

Welcome to the third instalment of our OSGi ABC tutorial. Please make sure you check both the 1st installment and the 2nd.

In this post, we will add another cache provider implementation to the mix as well as provide an HTTP front-end so the whole application can be tested.

First of all, let’s present a conceptual diagram of all the bundles and fragments involved so far.

Components diagram

Read on for more…

Continue reading

Posted in Computing, Java | Tagged , , , , | Leave a comment

Una mica de remember, no?

Simplement genial…

Aquesta cançó sí que és un bon punt i final a la dècada dels 80 (l’album “Autobiografía” va sortir el 89)

Posted in Catalan, Music, Random | Tagged , , | Leave a comment

Components on the server (2): creating the first bundles

Hopefully you enjoyed the OSGi journey in its first installment.

Though simple and easy to understand, the first example does nothing out of the ordinary. It is far more interesting to start exploiting some of the basic features OSGi gets us “for free”.

For instance, we could begin by moving our first basic implementation into a separate “model” bundle and enhancing the interface so it can throw exceptions. For instance, an exception can be thrown when no implementations are available or cannot be contacted/operated.

Read the rest of the post for the implementation details…

Continue reading

Posted in Computing, Java | Tagged , , | Leave a comment

Com passa el temps en el món de la indústria informàtica

Estava llegint l’article curtet de la BusinessWeek que comenta breument l’evolució de la situació d’Apple a nivell de borsa.

M’ha cridat l’atenció la següent llista del valor total de l’empresa (market cap):

Microsoft — $236 billion
Apple — $183 billion
Google — $176 billion
IBM — $162 billion
Cisco — $140 billion
HP — $115 billion
Oracle — $111 billion
Dell — $30 billion

Les accions pujen i baixen, però a hores d’ara aquesta és la situació. Com passa el temps i com canvien les coses, no?

Posted in Business, Catalan, Computing, Media | Tagged , , , | Leave a comment

Flash: the Wider Picture of an identy crisis

In this post I try to paint a bigger picture on the sneaky attack directed by major industry players to Adobe. Namely Apple, Google and Microsoft. There have been a number of seemingly unrelated news that will affect the status of Flash player as the prevalent media platform. Reasons for the upcoming struggle are varied but there are no bits of the overall Flash media platform left untargeted.

I will then get together some of the latest news and try to get the “Wider Picture”.

So, what makes an Internet media player an Internet Media Player Platform then?
In other words, a successful platform needs to establish itself on the Internet and WWW and be useful to distribute and enjoy multimedia content.

Nowadays, the most prevalent player is of course, Flash. But it did not used to be that way. Previously Windows Media Player was quite prevalent, fighting a war with QuickTime and Real Player, the later now pretty much being a thing of the past. Rhapsody notwithstanding.

But on what is Flash standing, really? In fact, it is standing on the pillars any other media playing architecture needs.

Media Player Architecture

These pillars can be listed as:

– An encoder, capable of live encoding
– A physical media container
– Support for at least one audio and video codec
– A live transmission system protocol
– For on-demand transmission we can assume HTTP is used for sanity
– A player runtime that can be distributed
– A container “plugin” or system to display the runtime on Web pages or on native apps
– Some kind of DRM system
– And finally, an established user base (or the whole thing is moot)

In the case of Adobe Flash, we can examine them:

– Encoder: check, Flash Media Encoder and others
– Physical format: .flv container format
– Video codec: On2 VP6 and lately H.264

Audio codec: MP3 and lately HE-AAC
– Live transmission: RTMP
– Player Runtime: the Flash runtime itself, capable of running ActionScript-generated bytecode
– Container: Flash Player Plugin
– DRM: indeed
– Established user base: near-ubiquity

All dots connect -and very well- in the case of Flash. In fact, some argue, myself included that lately Flash is just a glorified media player. There are a number of reasons of why this might be. My pet one is the following:

Take into consideration the enormous complexity of HTML+JS based Web App development, and that is the case even if you factor in the seemingly endless list of limitations and constraints imposed by the system. Let’s name some: poor support for local data storage, session-less basic protocol, slow character-based at that, massive rendering and composition constraints, limited animation support and a big etc. I do not need to continue.

Yeah, these are massive constraints. Bad as they are, they actually force on developers a set of paradigms that can be bent but not broken. A working set of variables that can be changed but not drastically. Constraints are sometimes design decisions, in fact, they are actually features if read from “outside the box”: rendering speed, readable, simple, reliable. Ah, the beauty of good design.

Flash, on the other hand, imposes far less of these constraints. Paradoxically, this enables hobbyist wannabe User Interface goons to go ahead and design fantastic-looking apps that look great but can’t be used. The demos look great and apps are demoed, sold, developed, deployed, suffered and quietly replaced by a faster, more serviceable JS-enabled app. I have seen this happening quite a few times myself. There you go. Read the lack of constraints from “outside the box” and you can get: slow, opaque, complex, crash-prone. Obviously if the UI goons are still in charge the simpler JS-enabled application will still be awful, but they can do less damage. But I digress.

Regardless of its shortcomings, Flash is today quite prevalent for video, “glorified media player” or not.

I would bet Google is not that happy that its YouTube video platform is Flash-based. I mean, one of your most strategic company assets relies completely on an external -and potentially competing- company???

This is okay for small fry, value-resellers and 99% of the companies out there, lest NIH syndrome bring your company down. So please don’t go out and start building your own microprocessors yet. One does not need to drink the OSS kool-aid to go on a limb and re-invent the wheel. Just keep an eye on your options, wink, wink. Just like any sane company should do.

But Google? You gotta be kidding. Hello?!? I am the ghost of the past and my name is WordPerfect. Gotcha.
Google excels and out of the box thinking, so eyes are kept at options wide open. Big time. There can be of course other, less obvious strategic concerns such as having viable options to provide media playback capabilities for Chrome-OS enabled devices.

Take another outta-box thinker, Apple. They surely are not happy about the Flash situation either. And well, they also seem to know what they are doing.

One obvious strategic concern is iPhone media playback both in and outside Web pages. Having Flash on the iPhone Safari browser would mean the Flash runtime ubiquity stretching even farther, leveling the media playback field even further. On the other hand, in the case of the iPhone, the video playback could be seen as collateral damage. The iPhone input capabilities paired to its powerful processing capabilities are in fact a good environment to deploy Flash on. I can see the minds of the developers: “great, we develop for the iPhone in the tried and true Adobe tool suite and we can deploy on Symbian, Android and WinMo in one go”. Wham! Flood of lowest-common denominator app, designed for wide market-share and running on a old, embedded-unfriendly runtime controlled by a third agent? You have to be kidding me again. Flash on the iPhone? It will not happen.

In the case of the iPhone, Apple knew they would shoot past the red waters of the pre-iPhone smartphone era into a blue sky. They also know that sky will darken, eventually. They have pressed their advantage in this emergent market. To paraphrase a former boss of mine: “Mobile will become THE platform”.

Apple is also concerned in the video playback in the desktop browser arena, even though that is perhaps less threatening to its plans. Ironically, in the case of Snow Leopard and its 64-bit Safari browser, Flash is running on a separate process so if you check it’s CPU usage it makes the plugin look really bad.

Microsoft is the uncle that has blown his family’s rich inheritance from a distant relative and then set fire to the barn. Windows Media used to be the leader video platform in the Web. They were readying themselves to obliterate MP3 from the market when YouTube struck with full force, playing Flash strengths: ubiquitous, multiplatform, hassle-free. I haven’t bothered to install Windows Media Player or it’s derivatives and I think I never will. I haven’t seen a .wma file in months and I don’t bother with the odd website that embeds WM, good riddance.

Pretty much everything in the consumer space seems to be a threat to MS lately: mobile, gaming, Web entertainment, set-top boxes, portable audio and a long et-cetera. Web and Internet playback are of course capital to its continued dominance of the consumer desktop, the real platform it stands on for its enterprise cas-cows. Distracted by Apple, Sony and the like, it forgot YouTube and Flash. Oh, and the official rival Google went ahead and bought them.

The battle lines are moving, can you spot them? To make them more obvious, we could do the mental exercise of going through the pillars that a video consumer architecture make and questioning what the aforementioned companies are doing about it:

– An encoder, capable of live encoding

In this case, pretty much all the companies have their own solution, plus the usual indies. Well, Google is not but I would not put it past them to be working on it. And there are always the OSS solutions, provided any licensing issues are cleared (hint, hint). Google thrives in the OSS environment and is quite well used in taking advantage of it -and of course contributing in turn-.

Although this is an important piece, it is far less visible to the consumer than any other pillars.

– A physical media container

Viable, established alternatives exist: the .MP4 physical container format, WMV to a lesser extent and the MPEG Transport Stream which in my opinion still has a lot of potential. All of them are well understood, well supported and most if not all are royalty-free. Both Apple and Microsoft are doing their best to keep their engines polished to support them. Google is again the elephant in the room.

IP on the .FLV physical container format is what Flash has on the plate to support this pillar.

– Support for at least one audio and video codec

This is where things get more interesting. The MPEG-4 Advanced Video Codec star, H.264 is gaining traction in the mobile arena thanks to the iPhone and other high-end phones. Apple is of course pushing hard on that and MPEG-4 on the iPhone will remain a point of resistance. Microsoft, as usual is pushing Windows Media as an alternative, specially with the Zune and WinMO, but it’s not looking that good.

But, hang on! Flash plays H.264 and AAC just perfectly thank you very much! The most likely reason for Adobe to adopt the codecs (and surely pay a steep fee to MPEG-LA) is that On2VP6 is showing it’s age and H.264 is really competitive. This means that big-profile clients like, erm, Google’s YouTube can optimise their video better and pay far less bandwidth costs (as they are already doing). Specially if you think big traffic like YouTube “big”. You can bet the small fry are also flocking to AVC Flash playback to save on costs. Vimeo anyone?

The blazing MPEG-4 codecs are like a double-edged sword to Adobe though. By adopting them Flash goes from a “glorified video player” to a “glorified MPEG-4 player”. The sharp edges of player interoperability are hidden within the package.

But, hang on! Google bought On2 Technologies! Uh-oh. Adobe doesn’t own the newest codecs and the old ones either. It is quite likely that the original deal between On2 and Adobe is long lived and contains many a safety blanket with a long period of exclusivity thrown in. Adobe have surely gone through the contracts inch by inch. Expiration clauses, opt-outs, etc.

Google made quite a big strategic acquisition here. Imagine, for a moment only, that they need a royalty-free codec to provide rich media playback for the Chrome OS. And imagine the exclusivity clause on the contract with Adobe expires, say, on the day of the Chrome OS release. And just go a little bit further: open up the IP of XXX with a suitable open license… There is more after the break.

But wait yet again! Isn’t VP6 old and not so competitive?!? Wouldn’t it take an army of extremely smart, dedicated and expensive researchers a lot of effort to improve it? Well, Google happens to have dozens of brilliant PhD-holding scientists who can also code that would be only too happy to take on such a challenge.

– A live transmission system protocol

We have mms:// languishing and rtsp:// not 100% successful, specially in comparison with rtmp:// and the clever workarounds found in competent Flash playback software such as Open Media Player. So that is another pillar that needs to be dealt with as no proper media playback system.

Apple has developed and proposed as a standard a streaming protocol that is pretty much HTTP. Check out the Akamai showcase. No firewall problems, no complicated delivery servers. Microsoft has also been busy on that side as well.

So Apple’s work is actually a proposed standard, ready for the taking of uh, the likes of Google. If Google were to implement http-based true streaming on YouTube, it would shave off a lot of costs on bandwith, infrastructure, etc.

Akamai gains would also be enormous benefit by simplifying its services and lowering its infrastructure costs by reducing the number of streaming architectures to support. Any other CDNs would as well, dragging the small fry with them.

– For on-demand transmission we can assume HTTP is used for sanity

A no-brainer, fully supported by pretty much anyone.

– A player runtime that can be distributed

The Flash runtime architecture and ActionScript 3 language are pretty mature now. Adobe Flash CS4 has unrivalled GUI design support and is in fact one of the company’s traditional strengths. In the meantime, Apple and Google’s efforts have concentrated on providing a viable and competitive runtime: Javascript.

Regardless of WebKit being adopted by Google on both the Chrome browser and Android, Google have gone ahead and built their own JS engine, V8. This ensures competition with SquirrelFish and will eventually drive the quality and speed of the engines forward. Add that to FireFox market share and MSIE 6 hopefully imminent demise and we have a viable playground for Javascript to become more stable and entrenched. In fact, the effect of these efforts on video playback can also be seen as “collateral” damage as a viable JS runtime environment is key to both Google and Apple strategies. This is specially true of Google and its online application strategy, key to its growth and long-term survival.

I am personally quite impressed by GWT and Google Wave, they are impressive engineering efforts. One could draw a parallel between AS3 plus the Flash Runtime and Java plus the Javascript runtime, with Javascript just being a simpler intermediate language for the different JIT JS runtimes to turn into native code. That is basically what the Adobe tech does, just pre-compiled. Pre-compiled JavaScript anyone?

The beauty of the GWT strategy is that Java coding tools are really mature and extremely powerful so we will see how that effort pays off. Isn’t it ironic that many Adobe tools are Java-based?

In the case of Google, using Java as the basis of Android and Eclipse as the basis of its development environment helps cement the Eclipse toolset as a powerful beacon. Regardless of the Java no-show on iPhone (another collateral), there is a subtle hint of renewed Java support by Apple, with the surprise appearance of the 32-bit Java 6 runtime in Snow Leopard. Ah, how IBM must be laughing at the strategic impact of its Eclipse gifts to the world.

Microsoft here is doing its copy-cat tactic, developing and then releasing Silverlight. Arguably, Silverlight’s implementation is more modern and neater than Flash and C# is probably a slightly better language. But it seems a “me-too” strategy and is simmetrically opposed to the Apple and Google strategies, which look more forward thinking to me.

In short, all players are coming up with powerful and viable alternatives to the AS3-Flash Runtime combo, supported on the shoulders of giants.

– A container “plugin” or system to be displayed on Web pages or on native apps

The ride gets bumpier here. It is no secret that both Apple and Google are champions of the upcoming HTML5 standard, helped in no small way by FireFox.

Enter the <VIDEO> tag in HTML5. There is little doubt that in the mobile browser arena the de-facto standard of video embedding will be through that harmless-looking tag, iPhone-thank-you very much. Apple is putting its money where its mouth is and has dozens of developers on WebKit, they will undoubtedly add support for <VIDEO> and this uniform single-source support will make it much more stable. Let’s go one vendor at a time: Google’s Android: no-brainer check, Symbian WebKit toting vendors: check, Opera: will have to follow suit, Symbian non-webkit browser vendors: going out of business anyway, Apple’s iPhone: check. Windows Mobile will either have to follow suit or be forced in a dark corner: either go on its own actively support its direct competitor Adobe with seamless Flash embedding. Microsoft is the underdog here, they will have to follow suit.

But wait, on mobile browsing Flash is already available as an alternative!

Yes, but it will never be available on the iPhone. With delicate irony the same pervasive multiplatform embedding support that made Flash-based video the king on desktop will be what hands it over to HTML5 on the mobile arena.

On the desktop things are slightly more complicated as Microsoft holds far more power with its large MSIE installed base, it’s not absolute power as it used to be but it can still stall and influence progress. The choices for MS are interesting: denying support for <VIDEO> completely would gain it time, defend WMV and stall Apple and Google’s advance, however, it would never be able to claim standards compliance. Microsoft has never cared for standards and has sometimes actively worked against them sometimes. However, forestalling <VIDEO> on the desktop would mean Flash is still king there, which doesn’t help Silverlight in any way. Would a weakened Flash pave the way for more Silverlight apps? Maybe, but it would be the final nail in WMV’s coffin, wouldn’t it? In any case, HTML5 is the standard and MS should at least feel some pressure and Flash continued dominance is not a rosy alternative either.

Another choice would be to grudginly support <VIDEO>, that would probably kill WMV off, inconvenience Adobe and hand the market to the other players.

More irony. It seems much hangs in the balance of Microsoft strategy here. But, besides mobile, there are two potential agent of pressure here, one is Firefox’s market-share growth which might continue and continue until MS is under 50%, difficult but not impossible. The other one is YouTube, Google needs to walk a fine line here, but as they have hinted to in the past, they are wiling to play hardball. A potential scenario would be to detect <VIDEO> enabled browsers and serve them the Flash-less video experience, perhaps add some better quality incentive or something. The immediately benefit for the user would be a better performing and smoother experience as there is no complex runtime to load that in the case of video playback doesn’t really add anything of value. This would help Firefox and other competing browsers grow even more marketshare.

Interesting conundrum: don’t support <VIDEO> to see MSIE drop it’s “standards support” badge and market share further eroded. Support <VIDEO> and see WMV weakened plus the general market browser interoperability increased. Or encourage Flash support and see Silverlight wither.

It seems MS is choosing option b) and supporting <VIDEO> as they seem to consider that option the least damaging to its plans. We’ll see.

– And finally, an established user base (or the whole thing is moot)

That is an interesting one, as Flash is well established in the desktop. However, also consider the combined Firefox, Safari and Chrome marketshare if they were to offer viable <VIDEO> implementations you would get an instant sizeable chunk of the market. Interesting.

In the mobile arena we have WebKit as the looming defacto standard. Again, instant market share.

Media Player Flash facing competition
In conclusion, powerful and determined players are preparing to fight the dominance of Adobe Flash in the Internet video market. The attack seems uncoordinated but all facets of Internet media playback are targeted from several directions, there are so many that I am having trouble drawing them all in one diagram. Powerful determined players like Google are entering the scene while established ones like Apple and Microsoft are re-entering the fray with renewed strength. Their strategies vary from conservative to novel thinking and blue sky reinvention. Adobe needs to start thinking alike or face a big identity crisis. Time to dump the stock?

Posted in Computing, Digital Video, Entertainment, Management, Media | Tagged , | 6 Comments