Conversation with a Web Thread

DD: Hi Mr. Web Thread and thanks for joining us.
WT: My pleasure. Do you mind if I stay in the pool?

DD: Hmm? Sure, why not. So, can you please tell us how is your life nowadays?
WT: Life has been pretty good. I have become very popular recently and came to perform some massive gigs in highly trafficked web sites. I really like this pool.

DD: Mmhh, okay. How do you think developers treat you, nowadays?
WT: Well, I am glad you ask. I think things have improved a lot, thanks to the emergence of concepts like continuations and AJAX. Still, I sometimes get badly beaten by some reckless coders. This pool is awesome.

DD: So, if you were to give a piece of advice to these programmers, what would it be?
WT: I think that these developers only need to understand what is the ultimate goal of my life.

DD: Which is?
WT: Coming back to that pool!

DD: Pardon me?
WT: You see, I get pulled of this pool very often and sometimes I am forced out of it for too long. In that case, I am like a fish out of water. And when I suffer like that, the whole application suffers.

DD: So what you are saying is that developers should thrive to let you return to the pool as quick as possible?
WT: Absolutely.

DD: Whatever the cost may be?
WT: Well, it depends of course, but if they can afford letting me return with slightly stale data, that is the thing to do.

DD: Where would they get such a stale data from?
WT: Oh, I realize I never introduced you to Mrs. Web Thread, née Cache. She usually takes care of this.

DD: But ladies, sorry, caches are complex. They require eviction strategies, invalidation messages broadcasts, etc.
WT: Or not. You can use a simple time-evicted opportunistic cache, provided it matches your business needs.

DD: Ah, I see, something like a 5 minutes cache.
WT: Or 5 seconds.

DD: You got to be kidding me, what's a 5 seconds cache worth?
WT: Do you have any idea of all the things I can do in 5 seconds? Do you realize that it is an agonizing eternity for me?

DD: Well, uh, I guess not. Let us lighten up the debate a little. Now that you are a rock star, thanks to your success in multi-million users web sites, do you get to sign a lot of autographs? Do people recognize you a lot?
WT: Sure, I can hardly go anywhere without being spotted. But, believe it or not, it still happens that I get mixed up with my cousins.

DD: Oh, you have cousins?
WT: Yes, Worker Thread and Background Thread. Sometimes, I get confused with one of them and receive way too much work to do or work that simply does not concern me at all.

DD: What do you do in that case?
WT: As I said before: I become grumpy and the whole web tier suffers with me too. I kind of like to share my pain!

DD: OK, Mr. Web Thread, I think it is time we wrap up now. Thanks a lot for your time and sharing your experience with us.
WT: You are welcome. Now back to the pool.

Splash!

Just Read: Statistics Hacks

More than twenty years after my last statistics class, this book really tasted like a rejuvenating read. It is well structured, with an opening focused on theory followed by numerous applications in all sorts of domains (yes, including poker, though my preferred subject was the Drake Equation). As such, the book will stand as a quick reference guide to which the reader will return every now and then.

Recommended for aging minds in need of a refresher (like mine) or curious minds wanting to learn more about statistics and how relevant they are to their every day's life.

As a side note, this is the first e-book I bought: I got it under EPUB format, which renders almost flawlessly on my Sony PSR-700 (texts, figures, schemas are good, very large tables are cut though). Kudos to O'Reilly who do a truly great job with their e-books, providing them in three formats and not limiting you in the number of times you download them (so I don't even bother backing-up my purchases).

Standards vs. Upgrade pains

In Standards Based vs. Standardized Neal Ford develops a very interesting rhetoric that is mainly focused on what he sees being "wrong with SOA (Service Oriented Architecture) in the way that it's being sold by vendors", but really touches a vast subject that has many thought provoking ramifications.

While considering the application upgrades I am involved in or that occur around me, it is clear that applications deployed on standardized platforms have easier upgrade paths. Or have they?

Let me consider the whole spectrum of applications I am involved with and discuss the related upgrade pains, how standards play a role there and if they are worth the effort. I won't discuss the necessity of upgrading application platforms: I reckon everybody feels the same itch when they see an application running on a platform that is many releases behind its current revision.

Non-standardized

Neal mentions ESBs as canonical non-standardized platforms, so I will start with them and consider my experience with following Mule versions. Many aspects of Mule are standards-based, from its protocol stacks to the zillions of libraries it is built upon (which I consider as being industry standards). Even its configuration mechanism piggybacks on Spring's schema driven configuration. What is not standardized are Mule's API and configuration syntax. Therefore they tend to evolve quickly, and sometimes drastically, as Mule expands and refines its feature base. Consequently, following Mule versions is not a small feat: it requires a pretty advanced knowledge of the platform to be performed right (and the assistance of extensive unit and integration tests, but everyone has this already, right?). Why would anyone willingly accept to jump through such hoops? Because it is worth it: being exposed to Mule's non-standard aspects is rewarded by a full access to its complete feature set and its full power.

Standardized

At the other end of the spectrum lies web applications that fully pack their dependencies and can be deployed on pretty much any container that understands their standardized configuration. A typical example is a Spring/Hibernate application deployed on JEE web container, like Tomcat or Jetty. It is to be noted that, even if this kind of applications can have very complex needs, their reliance on the JEE standard is actually quite small: a few entries in web.xml that hook some basic application entry points to the container and that is pretty much it. The rest is not standardized but fully resides in the realm of what the application controls (Spring and Hibernate configurations for example). Hence migrating between different versions or even different implementations of the JEE container is usually a no-brainer.

Somewhat standardized

Finally, in the middle of the spectrum, we find the applications deployed on platforms where standards fall short of allowing them to easily follow releases. Consider a full fledged JEE application, say deployed on JBoss. In this case, two forces act against the standard. The first one is the limitation in scope of this standard: anything that has been left to the interpretation of the implementor will likely differ enough between major releases to cause troubles. The second force is the fact that the standard itself is a keyhole applied against the full range of features of the platform itself: these features are there, accessible, often compelling, and it requires a lot of willpower to refuse to use them directly (by shielding them behind a custom facade) or not at all (by using extra dependencies to get these needed features). These two forces combined usually lead to full-range JEE applications that do not evolve gracefully when their underlying standardized platform is upgraded.

So, there is a clear trade off between having full access to a platform and being isolated from the disruptive aspects of its evolution over time. It is also true that standards with more teeth are probably needed (OSGi is an interesting one in this matter).

But everybody knew this already.

Two minutes on Ping.fm

Always interested in sharing the futility of my own existence, I thought that I could use Ping.fm to broadcast my boredom level (i.e. LinkedIn status) on different channels.

All went fine until I hit the page for connecting my Ping.fm account to my LinkedIn one. See for yourself:

Seriously, guys, you want the password of my LinkedIn account? Is this really the best we can do for integrating social networks? Are we waiting until the Wrath of OWASP falls on us to fix this?

Then I closed my Ping.fm account.

Integration Testing Asynchronous Services

Whether you use Mule or another integration framework, writing integration tests for asynchronous services can be a little tricky, as you may start running assertions in your main test thread while messages are still being processed.

Suppose you want to ensure that your content based router sends messages to the expected target services. Your integration test suite will consist in sending valid and invalid messages to the input channel in front of this router and check they end-up in the expected destination services.

But how to be sure that the delivery has happened and it is safe to start asserting values?

The naive solution to this problem consists in:

Thread.sleep(1000);

It is naive because it arbitrarily slows down your test suite without giving any guarantee that the message will be delivered. It may work on your machine but the same suite running on a busy integration server will behave very differently: one second may not be enough a wait if the threads handling the message delivery behind the scene are slower than usual.

A problematic fix to this broken solution consists in:

while (messageNotReceived) Thread.sleep(1000);

This is problematic because if, for any reason, the message does not hit the expected service, this loop will hang the test suite for ever. Of course, you can add a counter to limit the loop and reduce the sleep time to be more reactive, but this amounts to re-inventing the wheel when higher level concurrency primitives are ready-made for that.

Indeed, we can use a countdown latch to hold the main test thread until the message hits the expected service. Here is the code I use for my Mule integration testing:
<br />private MuleMessage getMessageReceivedByService(final Runnable testAction,<br /> final String expectedServiceName) throws Exception {<br /><br /> final AtomicReference<MuleEventContext> muleEventContextReference =<br /> new AtomicReference<MuleEventContext>();<br /><br /> final CountDownLatch latch = new CountDownLatch(1);<br /><br /> muleContext.registerListener(new FunctionalTestNotificationListener() {<br /> @Override<br /> public void onNotification(final ServerNotification notification) {<br /> if (expectedServiceName.equals(notification.getResourceIdentifier())) {<br /> final FunctionalTestNotification functionalTestNotification = (FunctionalTestNotification) notification;<br /> muleEventContextReference.set(functionalTestNotification.getEventContext());<br /> latch.countDown();<br /> }<br /> }<br /> });<br /><br /> testAction.run();<br /><br /> assertTrue("Message did not reach service on time", latch.await(15,<br /> TimeUnit.SECONDS));<br /><br /> return muleEventContextReference.get().getMessage();<br />}<br />
I leverage the notification mechanism of Mule and the capacity its functional test component has to broadcast such an event when it is hit by a message. Though a Mule specific implementation, the design principle I discuss here is applicable to other situations.

Notice how I pass the triggering action of the test (like sending a message with the MuleClient) as a Runnable to this method. This allows me to prepare a latch and register a listener before calling this Runnable and, then, to wait on the latch until it is lowered. When the execution comes back to the caller method, it can safely assess properties on the received message.

Obviously, the test is designed so its normal execution leads to a message always hitting the right service. Hence, in practice, the wait on the latch is very short, way under the safeguard timeout of 15 seconds.

But what if we want to test that no message will hit a particular service?

This is when things get tricky with asynchronous testing, because there is not systematic approach to testing the absence of an event when it can occur unpredictably in the future.

One strategy I use is to turn the problem around and change the negative assertion into a positive one. For example, by always ensuring a message will go somewhere, even if it is a service that sends messages to oblivion. By doing so, instead of testing that a bad message never hits a good service, I test that a bad message hits the oblivion service.

Do you have other advices to share about asynchronous testing?

The Sin of Generalization

The more I progress in my journey as a software engineer, the more I realize how our profession suffers from the Sin of Generalization. The good news is that this sin can be fought with a rope and a mast. Let me explain.

This almost deadly sin manifests itself in two ways:

• A tool or a methodology that has been sucessful in one context gets generalized and becomes applied to other contexts, where it ill fits.
• A generic platform or framework is created to solve all sorts of needs, while ad hoc solutions would have been more straight to the point.

This may sound funny from me, as I am the lead of NxBRE, a .NET generalized rule engine! The reality is that NxBRE, like all rules engines and al generalized tools, has a sweet spot where its usage makes sense. Outside of this sweet spot, using a generalized tool is in fact counterproductive, because the indiosyncracies it is bringing (limitations, bugs, specific configuration...) outweight its benefits.

Of course, there is value in re-use and generic tools. The point of the matter is that it is always worth considering the relevance of a generic tool or methodology everytime you intend to use it. This sounds like an obvious statement but experience shows that generalized solutions are as attractive and noxious as sirens.

Hence the rope and the mast.

Mule in Action, the Making of

Now that dust has started to settle, I have some time to reflect on writing Mule in Action and share my experience with this process.

I will spare you the "it's a long and exhausting process that is a true trial for one's will", because you already know that such an endeavor requires a personal investment that is beyond whatever time-consuming hobby you could have (that is basically about sacrificing all evenings and Saturdays on the altar of authorship for a solid 6 months).

A technical book like Mule in Action gets its relevance from the richness and correctness of the examples it contains. Inspired by Brian Goetz's experience about writing Java Concurrency in Practice, John and I have decided to treat our examples like a full fledged project. For this we have created a Google code project and built all the samples with Maven. These examples are sometimes started by a command line script, but the true value resides in the unit and integration tests that cover them.

These tests are a life saver because the community edition of Mule 2, especially in its early days, was a moving target, with non-backward compatible API changes and deep behavioral alteration occurring between releases. Any time a new version of Mule is released, we upgrade to it and run a full build of the book examples. Anything that breaks signals a potential change in the book itself. But how do we know if the book needs to be changed and where?

We did not use a code extraction/insertion script, like Brian did, but we decided to enable a complete traceability by tagging our code fragments and keeping this tag along them in a hidden field in the body of the book. This way, whenever we modify the source code, we know if and where the book is affected.

This leads us to the format of the book itself. We opted for DocBook, which is "just" XML backed by a schema. What does this gives us? First, the possibility to grep for a specific code tag or sentence and replace using simple commands. Second, the possibility to diff two versions of the text (because, of course, we store all the chapters and related images in Subversion): this is extremely convenient in a multi-author environment like ours. And, finally, the possibility to use a simple but strict writing environment. Indeed, you do not need a word processor for writing a book: it is just a useless collection of bells and whistles. Any editor with schema validation and a basic spell checker is all you need.

That is for the tooling but what about the practice itself? I have quickly realized that, like a movie, a book is produced in an out-of-order manner. Trying to write a whole chapter in the reading order is futile and could lead to a very frustrating writer's block. Once I started to accept this idea, writing became way easier, with chapters appearing in the order inspiration was leading me to and backing code samples where being created. Even for a purely technical book, inspiration matters: it is a pretty stubborn animal that goes only the way it wants (am I talking about Mule?) and must not be forced otherwise.

Finally, I have found that music was an extremely powerful productivity booster. Maintaining a high productivity is essential for such a technical book, which is condemned to premature obsolescence if it is not written within a short period of time. Listening to lyric-less music was for me a way to boostrap my writing sessions, while oftentimes I would have preferred to call the day over and get some rest!

We struggled hard to stay away from writing a user guide, which is available on-line anyway, and opted to focus on practical examples touching most of the common and advanced usage of this ESB. Hopefully, the book will prove good enough for our readers to get both a deep and wide coverage of Mule.

Beware Phony Model Objects!

While I am refactoring huge amounts of code out of EJB2 (and trying not to break too much things), I have noticed a bad design pattern that is so noxious I thought I should blog about it.

I call this the Phony Model Objects (PMO) antipattern.

It basically amounts to sharing as first class model objects entities that should never be publicly exposed. These bad citizens may look inocuous at first glance. In fact, they oftentimes carry a deep functional dependency on the technical framework they depend from or are subject to change at a different pace than actual domain objects would do it.

Interestingly I have found that all these PMOs are generated: whether they are EJB2 artifacts (home interfaces, entity beans, value objects, primary keys...) or web service client stubs. This re-enforces the idea that they are by-products and should be treated as such.

So, if you return or accept this kind of PMOs in public methods, do not wait and immediately refactor your code to share only proper domain model objects and keep the phony ones hidden behind the surface of your API.

This will eventually save you a lot of pain and efforts when the technical framework to which your PMOs happen to be coupled to will disappear and you will have to move away from them. Trust me on that one!

MuleCast: A Conversation with the creator of the JCR Transport

Ross Mason has interviewed me (again) about the JCR transport for Mule. I also had a chance to give a few words about the brand new Common Retry Policies module.

Enjoy!

A month of e-reading

After months of procrastination, I have decided to give a try to e-ink and go paperless as much as I can. I have been using a Sony PRS-700 for a month now and I must say I am really happy with it.

This picture does not render the actual contrast and precision of the e-ink surface.

I opted for the Sony reader because of its openness: you plug it in an USB port and voila! You are free to drag and drop files into the reader.

I used it in all sorts of lighting and places: in the dim light and shaky environment of public transportation to the comfort of a sun lit office. So far I successfully used it for:

• Paperless meetings: instead of printing meetings' material, I now upload them to my reader.
  
• Long blog entries: I simply can not read long articles on a computer screen so I use the reader for long blog posts.
  
• Reference guides: the search feature of the reader is convenient to find passages of reference guides or technical books (like Mule in Action).
• Book reviews: instead of printing the books I am reviewing, I now upload them to the reader. The annotation feature is a little too slow to take long notes on pages but fast enough to attach a few words that are reminders for building the final review.
  
• Full fledged e-book of course! So far, I have only read a few technical e-books from InfoQ. Hundreds of pages later, I can tell it is really a great reading experience. I sometimes have to zoom on a schema, but most of the time using the landscape orientation guarantees a seamless reading.
  

Despite wishing a bigger screen for a smaller price (it's Christmas time after all), my only concrete suggestion to Sony would be the addition of a smart zoom mode that would automatically trim all the useless white margins that oftentimes waste PDFs' page estate.

How To Guarantee That Your Software Will Suck

You may have recently read two eponymic blog posts about this crucial subject, so I won't give you ten more ways to suck at programming but just one.

Here it is:

Don't critique your code.

If you never ever have a critique view of your code, you are on your way to write software that sucks.

People who pair program may chuckle: they already have a continuous critique process that helps producing high quality code. People who practice code reviews may chuckle too: they already have a process (and, often, tools) for ensuring code is properly discussed.

So what is left for those who do not pair program or practice code review? The same applies: whenever you come back to your own code, critique it. Oftentimes, while adding a new feature, you will realize that a particular design is convoluted, a class is ill named or a method is hard to read.

Do not fall into complacency with your own code: love it, hate it, critique it, refactor it!

Software That Kills

In the latest installment of his monthly IEEE Software column, Philippe Kruchten asks about the relevance of licensing software engineers. In this article, he states:

The only purpose of licensing software engineers is to protect the public.

He then details the reasons why it makes sense to license people who write or certify “software-that-kills”.

Even if I am not licensed (and may never be), I fully agree with his positions. In fact, I feel compelled to ask why limiting licensing only to software that kills people. What about software that kills businesses? What about software that kills privacy?

Except when human lives are in jeopardy, software developers are basically free to do whatever they want when they build an application. Businesses and end users are left to goodwill and luck when it comes to receiving from software developers the professional standards they can legitimately expect from them.

Should licensed software engineers be engaged to at least review the design and architecture of software that can kill businesses or privacy? Would it be enough to restore trust in a profession from which the common wisdom is to expect so few?

A new module for Mule!

I am happy to announce the very first release of the Common Retry Policies module for Mule 2.

The goal of this project is to encourage the Mule community to nurture a set of production grade retry policies. At this point, the available policies have been tested only with a limited set of transports (JCR with JBossMQ and ActiveMQ).

I expect the feedback of the community under several forms:

• Configuration samples that worked for you,
• Bug reports, fixes and improvement patches,
• Features requests.

Visit the project page for configuration samples, links to the downloadable artifacts (Maven, standalone distribution) and to JIRA.

Hope in hardship?

Hard times provide opportunity for change. Can't afford for a project to fail? Applying agile development principles can help. Doing projects with fewer people? Applying agile development principles can help. Limited resources throw options in sharp relief where a surfeit of resources makes putting off change easier.

Kent Beck, posted in Agile Interest Group Luxembourg

Right now every organisation is assessing all their costs (most companies have cut between 10-30% of their workforce). In this process, CIO and Managers are being asked to do more with less, to keep the engine running with half the budget. This means they have to look to open source.

Ross Mason, from his blog.

These sound like there is a future for agile minded open source addicted developers out there. Time will tell...

Last Night Eclipse Demo Camp

I attended my first Eclipse Demo Camp last night in Vancouver and it was really a great event! Of course, the profusion of food and beer offered by the Eclipse Foundation at the end of the evening surely helped building such a great impression...

The whole evening was driven by the Tasktop guys, which gave us a chance to get a feel of the interesting ecosystem that is growing around Mylyn. I would like to turn the spotlight on two projects which are worth discovering on your own:

• Tripoli, an EclEmma-powered code coverage diff tool that allows you to pinpoint issues in an efficient manner.
• TOD, a so-called omniscient debugger that allows you to do back-in-time debugging without a DeLorean (which made me think a lot about what ReplaySolutions is building).
  

These two projects are brilliant illustrations that academia can produce concrete results in software engineering. That is surely encouraging for practitioners!

As a closing note, if you happen to be in Luxembourg tomorrow evening be sure to hit the Eclipse Demo Camp over there. You will have a chance to see Pierre-Antoine and Fabrice live, which is really worth the trip!

Mulecast: “Mule in Action” book interview

Ross Mason has interviewed John D'Emic and I about Mule in Action.

If you listen to the podcast, you will get a 27% discount voucher as a compensation for ear damages caused by my broken English.

Isn't life a bliss?

Seven Years To Rot

So here we are, seven years after the Manifesto, and the webersphere is pontificating about the decline of agile, to the point that Uncle Bob has hard time containing his anger in front of such a display of nonsense and dishonesty.

What is going on with agile? After seven years of existence (I know, the techniques and approaches agile promotes predate the Manifesto), has it started to rot?

Some suggest that agile is following the Gartner hype-cycle and has now past its "peak of inflated expectations":


Of course, there is hype around agile and the diatribe of some of its fanatics can be a little over the top. But I think that the current "decline" in agile is not due to some disillusionment.

I think this so-called "decline" comes from the numerous software sweat shops and less-than average programmers who started to pretend they do "agile" without changing anything in their craftsmanship. Instead of a disillusionment, agile suffers from dilution.

Hopefully, people will be able to sort the wheat from the chaff and debunk these agile fraudsters. When this will happen, agile will start climbing its "slope of enlightenment".

The Path of Least Resistance

While fighting with monsters of legacy code, I have kept thinking of all the possible reasons why developers would end up building such a man-made hell. My capacity to analyze the situation and figure out possible causes is limited to the knowledge of the external forces that these developers where exposed to. For what was happening inside of them, I am limited to build analogies after looking at my own battles and shortcomings.

I have been trying to distill a unique question. Here it is: why would a developer choose to the walk the path of least resistance?

Though skill, experience and professional standards are factors at play, I do not think they can explain the whole picture. Deadline pressure certainly encourage to cut corners and follow the easiest and dirtiest path. But the crux of the problem is not there. It is in the resistance.

What is this resistance anyway? It is multiform and hard to characterize. Any developer surely has felt at least once the slight despair it entails: you want to progress and get blocked by a wall of resistance that is not insurmountable but would incur a great cost in term of work disturbance.

Here are a few example of the outcome produced by such a resistance:

• Teams entrenched behind layers of management feel encouraged not to wait for the others to do something that they need and end-up building sub-optimal solutions with what they have now.
• High cost of database changes can drive developers to extremes like the reuse of existing fields, the use of inadequate field types or the storage of serialized objects in BLOBs when a few extra columns would have done the trick.
• Long feedback loops between a code change and the result of testing orient developers towards implementing new features with minimal changes to existing code, which ends up with code duplication, spaghetti plates and design-less applications.
  

Facing resistance, it is very hard for a developer to postpone the completion of his work because, when he is building something, he is driven by the goal to reach and tend to disregard warning signs. This is the same challenge that airplane pilots face when their guts tell them to stay on the ground or to turn back but their focus on reaching the planned destination make them fly into trouble. The only difference is that, oftentimes, these pilots will not survive their decision to ignore warnings, while in software we can move on to a new job and pretend nothing happened.

Taking intelligent decisions while being goal driven is hard. Everybody knows that the path of least resistance is rarely the best one. Alas, we walk it and, I suspect, not by laziness but by renouncement.

Just Read: Facts and Fallacies of Software Engineering

Sometimes, when I read a book, I look at the publication date and wonder out loud: "what on earth was I doing this year to miss this one?". This is exactly what happened while reading this book from by Robert L. Glass. What on earth was I doing in 2002 to have missed such an excellent book?

Known as the F-Book, after its original title proposition ("Fifty-Five Frequently Forgotten Fundamental Facts (and a Few Fallacies) about Software Engineering", which thankfully was not kept by the editor), this dense book is truly the sum of all truths and untruths about software engineering.

This book is really invaluable as an aid for debunking hype of all sorts and performing reality checks on tools and methods that oftentimes are dumped on software engineers with the promise of a brighter future (that never materializes).

With half a century in the field, Robert has seen it all and heard it all already. If you think your problems or questions are new or unique, then read this book and keep it, because you will have to come back to it and quote it whenever you will need to challenge a snake-oil vendors or an ivory tower methodologists (pretty much like you do with the anti-patterns catalog for development mispractices).

Silver Still Very Light

I have just switched to the latest version of Moonlight, the port of Microsoft Silverlight on Linux, and the least I can say is that things have significantly progressed since the last time I tried.

So far, I have found only one site of use whose Silverlight application runs fine on Linux: the Ryanair destination map. Though the plug-in reports a rendering speed of close to 100 FPS, the zooming and panning is still way behind what pure JavaScript or Flash applications provide. But it is very impressive already.

The only problem seems to reside in the Silverlight detection algorithm used by most of the sites. Most of them give me the Redmond finger:


... while Moonlight is there and ready to chew XAML and render it! Too bad, I would like to see more of these sites and keep track on how this runner up technology will compete with the ones already in place.

At the end of the day, I have no doubt Silverlight/Moonlight can become a credible alternative to the current RIA browser-side technologies. My main concern is that sloppy developers may create Silverlight-powered sites that will only work with a limited set of platforms (browsers, OSes), which would be a regression from the current state of the web nation.