Computing – Page 2 – The moons of Verthandi

Flash on iPhone OS: two extra reality checks

Unless you live in a remote and far away place you will have heard of the media impact of Apple’s decision to ban the Adobe Flash to iPhone solution and the various discussions that have ensued. I won’t bother with providing more links. I love John Gruber’s take and Louis Gerbarg’s as well.

Both J.G. and L.G. have brought up many valid points: Adobe dragged their heels on Flash for mobile for a looooong time. There have been countless detabes and blog posts.

I’ll bring two further arguments, one logical and one historical, the latter being one that I believe hasn’t been brought up yet.

Logical argument: the fallacy of Flash being cross-platform

Moreover, why should we choose to lock ourselves onto Adobe’s propietary API instead of Apple’s propietary API? Why is Adobe’s API, specs and runtime superior to any others? Many would say the main reason (the only?) is that it’s crossplatform?

Wikipedia says that cross-platform means:

“an attribute conferred to computer software or computing methods and concepts that are implemented and inter-operate on multiple computer platforms”.

Oh, okay, so multiple means Windows, Mac and Linux desktops. Hello?!? Anyone there?!? This is 2010 and the 90’s called because they want their meaning of “platform” back. Nowadays, multiple means desktop and mobile. Therefore:

Flash Lite is a joke. Where are the multiplicity of mobile devices supporting proper Flash 10.1 today?
Where is the pervasive Android support today? HTC Hero buyers are screwed, a phone bought as little as less than a year ago won’t be supported.
Where is the support for Windows Mobile devices? Not there until WinMo7. You mean it will be supported on a OS that it’s not even there yet?

Well, you could say that the Open Screen Project and the releasing of the FLV, SWF and the lot specs are true multiplatformness… Well, so far so good but where is the real market traction? Where are the tried-and-true implementations? Adobe has released this technology but until it gains traction it’s no more than a glorified press release. Apple can play this game too, with tech such as WebKit which is used in a zillion places including Adobe’s own Air platform. Press releases and freeing technologies are irrelevant until adopted. A good initiative which I applaud, but still not widely used.

No, Flash is not cross-platform anymore. What is the marketshare of the mobile devices capable of running Flash 10.1? Nowhere big enough for Adobe to be pulling muscle and demanding anything. It seems Adobe is using Flash devs and aficionados as cannon fodder or -as Gerbarg more aptly puts it-, “Adobe used its userbase and their livelihood as a bargaining chip”. Adobe dragged its feet for years in the mobile arena and now is paying for its mistakes.

Historical argument: ~~Macromedia~~ Adobe has screwed its own developers like this before

In the nineties Macromedia had a great product already. It was cross-platform (as per 90’s definition), had powerful scripting capabilities, an powerful extension architecture, a great browser plug-in runtime that was also cross-platform, video capabilities, awesome rapid development tools, stellar graphics integration, built-in debugger, great performance, etc. It was called Director and it was really cool.

Then Macromedia bought FutureSplash in 1996 which would be later renamed to Flash. It had far less capabilities that Director at the time (no real scripting at the beginning, etc.) and would remain technically inferior for sometime, having no debugging and many other features being missing for a long while. However, it had three distinct advantages. Strike one: having less features and being a newer codebase meant it could have a more lightweight runtime than the Director one. Strike two: it had support for vector graphics, which desktop CPUs at the time were just capable of displaying and animating adequately. Director came from a less CPU-intensive bitmap background, faster but consuming more space than vector definitions and looking less sleek in many cases.

One “advantage” remained. So what did Macromedia do? Take advantage of the FutureSplash technology acquisition and the Director established developer base? It could have easily added the vector drawing technology into Director (it supported many types of media already). Refactoring the code and runtime would be no trivial feat but doable. Any Director developer would have been OK with a new restriction being put into place that meant only vector-graphics resources being allowed any new Director web runtime, would have welcomed and embraced such a change.

Strike three: Macromedia realised that with the maturity and feature-complete of Director no long-winded upgrade path was in sight. Just adding vector graphics and a streamlined runtime would do for one or two Director upgrades, no more. They thoroughly screwed the existing loyal developer base royally and released a sleek new 1.0 Flash product. Then they spent years releasing upgrades that added features that had already been present in Director for some time. They created another cash cow, a cow that would ride the wave of the Web explosion of the .com era. Director out. And no, I’m not buying any of the “official” reasons for its languishing and Flash emergence. It was all about money.

I am not crying for Director’s demise -or rather, being put into life-support mode. It was a good platform and many (myself included) made good money using it. This doesn’t mean Adobe didn’t screw up many of its own developers and went in for the next cash cow.

I am not buying Flash developers and supporters taking offense and the moral high ground, the company (now Adobe) you support has done a much worse thing to its own developers. Why should Apple even care for developers of other platforms? Just because you learned a framework and are scared of it fading away doesn’t mean anything… Some of us have done this many times before and moved on…

Final word: put your code where your mouth is

Okay. Time to recap, folks. If Flash is such a great platform -it’s actually not bad but not that good either- go ahead and develop these killer apps on Android or WinMo7 whenever that comes out. With killer apps being available on competing platforms making a huge difference Apple will simply change the clause and allow you in. They’re not stupid.

Now stop crying and start coding. Myself, will try to put this out of my mind.

Apple i Google: I això que no eren amics…

Els de Gizmodo ens han regalat una xafarderia un xic inusual… L’Eric Schmidt de Google i el Steve Jobs d’Apple prenent un café en un bar de Palo Alto.

I això que teòricament estaven en “peu de guerra“. Serà que han enterrat la destral…?

Firefox for N900 with Flash disabled. Ah, the irony…

From the Firefox for Nokia N900 1.0 release notes themselves, stumbled upon this little gem:

Initially, Firefox for N900 does not support browser plug-ins. Due to performance problems using Adobe Flash within Firefox on many websites, especially those with multiple plug-ins on them, we have disabled plugins for Firefox for Maemo 1.0. We plan to provide a browser add-on that will enable you to selectively enable plugins on certain sites, because some sites, like YouTube, work well.

So the good folks of the Mozilla Foundation have gone and released the thing. Given the recent turn of events, it’s interesting to see the reality brick hitting the Adobe head, so to speak. Couldn’t think of a more appropriate support for the Apple iPad, really.

Even if the eventually release it with plug-in support enabled, they will probably stick with letting users enable Flash selectively… This is yet another nail in the Flash coffin.

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.

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 “Components on the server (5): better Unit Testing”

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:
<servlet-class>org.eclipse.equinox.servletbridge.BridgeServlet</servlet-class> <init-param> <param-name>commandline</param-name> <param-value>-console</param-value> </init-param> <init-param> <param-name>enableFrameworkControls</param-name> <param-value>true</param-value> </init-param>

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:
com.calidos.dani.osgi.cache.controller_1.0.0.beta.jar com.calidos.dani.osgi.cache.frontend.http_1.0.0.beta.jar com.calidos.dani.osgi.cache.log4jconfig_1.0.0.beta.jar com.calidos.dani.osgi.cache.provider.memcached_1.0.0.beta.jar com.calidos.dani.osgi.cache.provider.memory_0.0.1.dev.jar

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:
org.eclipse.equinox.registry_3.4.100.v20090520-1800.jar org.eclipse.osgi.services_3.2.0.v20090520-1800.jar org.eclipse.osgi.util_3.2.0.v20090520-1800.jar org.eclipse.osgi_3.5.1.R35x_v20090827.jar

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:
org.apache.log4j_1.2.13.v200903072027.jar org.eclipse.equinox.common_3.5.1.R35x_v20090807-1100.jar org.eclipse.equinox.http.registry_1.0.200.v20090520-1800.jar org.eclipse.equinox.http.servlet_1.0.200.v20090520-1800.jar org.eclipse.equinox.registry_3.4.100.v20090520-1800.jar

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:
org.eclipse.equinox.http.servletbridge_1.0.200.200911180023.jar javax.servlet_2.4.0.200911240836.jar

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, \ com.calidos.dani.osgi.cache.frontend.http@5:start

osgi.bundles.defaultStartLevel=4

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.

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 “Components on the server (3): adding a HTTP frontend”

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 “Components on the server (2): creating the first bundles”

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?