Alex Russell has another one of his insightful posts titled Power and Authority. He talks about the core tenets and then ties it to the W3C, and who we should be "blaming" for the slow upgrade of the Web, and it requires a look in the mirror:

As a case study in putting your faith in the wrong idols, you can’t do better than posts like this which “blame the W3C” (via Molly). Blaming the W3C for not pushing the web forward is both humorously off-target and distressingly common. I’ve written about this before, but fundamentally you can’t blame the W3C for failing to act because it’s not the W3C’s job to act. An MBA should be able to tease this out a bit more effectively – any decision only requires that you have answers for five questions: why? what? how? when? who?

Answering these for pushing the web forward is straightforward, even on a simplistic level:

• Why?: it’s too hard to build reasonably sophisticated interactions with current web technology
• What?: new tags, JS and DOM APIs, CSS syntax, and renderer support for all of the above. Eventually, a spec or five reflecting these new technologies.
• How?: we could try asking the W3C to do it, but they don’t have any power. When they’ve been left to their own devices, the W3C has failed. Miserably. Over and over and over again. Instead, browser makers should introduce new stuff and then agree to agree on it (via the W3C or similar organizations).
• When?: introducing new features in any given browser seems doable in short-order. In the case of Open Source browsers, the answer is “as soon as someone decides to invest in them”. Competition has even spurred Microsoft to some level of action. The likely time-scale for new features over all, though, appears to be on the order of 5+ years. That’s clearly not soon enough.
  TODO: investigate ways to speed this up.
• Who?: browser makers and others in a position to affect the code that goes into the renderers we use.

Figuring out “how” leads you directly to “who” in this case. The action we all want is the sole purview and responsibility of the browser vendors and they alone have the power to push the web forward. The “web standards community” has made it clear that they’ll need the imprimatur of some authoritative body where agreement can be forced, but that hasn’t kept the browser vendors from taking the initiative there, either. The big, open questions then center around how the “web standards community” can make enough room for renderer vendors to try out new stuff, since that’s how we get new things. Demanding agreement on what to do before trying it out demonstrably doesn’t work, so it’s then imperative that there be a mechanism for the web to iterate prior to standardization. In fact, I’ll argue that this is now the biggest reason that Paul Ellis isn’t getting the improvements he wants out of the web: there’s no mechanism in place by which any browser vendor can take significant risks without incurring the wrath of a swarm of WaSPs, or worse. Attempts to even begin to lay the groundwork for such a mechanism have been shot down forcefully by may folks who, like Paul, view “fixing the web” as the W3C’s job.

Standards bodies are animated only by the needs of industry to reduce costs by forcing vendors to agree on things. Like Open Source, they can act as a back-stop to the monopoly-creating power of network effects by ensuring that the price of software commodities eventually does reach zero. In this context, then, the W3C’s only effective function is to drive consensus when visions for how to go forward diverge or lead down proprietary ratholes. Asking the W3C for more is the fast path to continued disappointment.

The W3C is just a sail and all sails need the wind to function. You can’t blame the sail for the wind not blowing.

Michael Mahemoff has a nice little post on the rebranding of JavaScript. It kicked off when he was listening to Steve Yegge on rebranding:

He talks about how languages are branded, e.g. “Java” is enterprise. One of his main points is that brands are “const identifiers”, i.e. it takes an entire generation to change brand perception, so it’s often more effective to simply re-brand. e.g. GTE had a poor brand, so they tried a self-deprecating ad campaign, which backfired, and subsequently re-branded to Verizon.

He then mentions Javascript has a branding problem, because it represents “browser” and “toy language” and “damnit, I gotta learn Javascript” and it’s the language no-one wants to use. He also notes the name itself isn’t great either, nor the rhino imagery. (I’m not sure why Steve assumed many programmers would associate Javascript with rhinos; the Rhino product and O’Reilly cover weren’t really promiment enough to do that; rhino ain’t camel!).

But, wait a minute, didn't we already have a rebranding?

Javascript has already been rebranded. In fact, I’d go so far as to say “Ajax” was one of the most successful rebrandings in software history.

Although technically Ajax != JavaScript, and the rebranding is really DHTML, he is right. Ajax rebranded the Web, and we have all benefited from it.

I also think that this is just the beginning, and we haven't seen the best of the Ajax revolution yet.

Webmonkey was a great resource for us when we the Web took off, and it was a shame to see it die out. Today we saw that Webmonkey has been re-born as Conde bought it back and put the content back online.

We have also republished the bulk of Webmonkey’s vast library of tutorials and reference guides on a wiki. With very few exceptions, every page in the tutorials, reference and code library sections of the site is publicly editable. We’re using MediaWiki’s open source software to host the content.

Some new things you’ll notice:

* Articles can be tagged and rated.

* Each page has its own backchannel for comments and discussion.

* Registered users get profile pages where they can talk about their projects and list the sites they’ve built.

* We’re still in the beta phase. Webmonkey is, and will continue to be, a constant work in progress. If you run into trouble, check the FAQ or drop us a line. We’ve set up a wiki page for bug tracking, so if you see something that doesn’t quite look right, let us know.

Welcome back. Now you can join the other Web monkeys out there (from Tamarin to ActionMonkey).

OpenEXT is here. It is a fork of Ext JS 2.0.2, which was under an LGPL license (kinda.... with some invalid, non-open source licensing).

The crux of the fork is:

Ext are claiming that a fork of the existing 2.0 version is not legal, due to the way they applied the LGPL. This is likely to be incorrect, and if correct then their use of the name LGPL was grossly misleading.

At this point, developers are getting increasingly passionate, and Jack needs to make a big effort and come clean to his community to save the reputation of the project. If not, it will probably always be in a cloud of darkness as people are both confused and wonder about motives. This is not about personal attacks, but due to not having clarity on the core issues.

You will notice that most of the detractors are members of the Ext community. They aren't out to spoil some of the work that they themselves put into the project. You see the opposite in fact when you read posts such as this one from Jason Sankey:

The saddest part about this is that the Ext team really have built a fantastic library, and a vibrant community around it. The library had all the hallmarks of an open source success story. Now, however, Ext have committed the cardinal sin of an open source project: they have undermined the trust of their own community.

There are others too.

I actually believe that Jack has been given really poor legal advice, which hasn't helped his thinking on the issue. It has thus spiraled out of control, and needs a big humble gesture to steer things in the other direction.

If I were Jack, I would call a meeting (phone, irc, whatever) and get all of the parties together. Hash it out with an open mind, and end up with the right answer. Again, this is for the sake of the Ext JS community, customers, as well as the entire open source JavaScript community. If this doesn't happen, you are keeping the cloud around the project, and handing contributors to other projects. No-one wants to see this happen.

In my opinion the way to protect your business and the project, isn't through a license to protect the forking. If you have a healthy strong community, any fork by someone wouldn't put much of a dent in you... as who would go with BobsExt when they can get the real deal. Of course, the reverse is also true, and tearing the community apart will lead to a world where you will never find the true potential.

I have just posted an article on the new attack on the RDBMS on my personal blog. The post talks about the new thinking around data in the cloud, and on the Web. It first starts out by remembering that this isn't the first time the RDBMS has been attacked, and remembers the OODBMS attack, which didn't do too well. Then it gets into the cloud-y Web:

SQL is an enterprise victory that managed to make its way into the consumer Web and application space. A lot of people knew SQL, and it seemed obvious to have a LAMP stack or a Java / .NET stack backed by a RDBMS.

Is this really the right choice for Web applications? Why was Rails so successful? It was due to the productivity gain. How much of that is due to ActiveRecord vs. the other Action* pieces that make up Rails? I would argue a large percentage. Working with the database was actually a big pain in the tuches. ActiveRecord together with migrations helped a lot. It gave us a nice middle man between a full ORM and the SQL that we know and …. know.

What if the database piece didn’t need to be that painful? The source of the pain can be the paradigm shift between the various worlds, but also a huge part of it is scalability. When you have to scale your website, it can be fairly easy to make your application stateless, and then the bottleneck becomes the poor database. This is when you break out the master / slave relationships, think about partitioning of the application, and caching layers (Tangosol Coherence, memcached). Now you have to really think about an architecture ;)

Google had to do this thinking a long time ago, as they obviously have to scale their applications to a huge degree. Scaling the fairly read-only search operation is one thing, but as soon as you get to read-write operations you have a lot more of a head-ache. Scaling a MMORG astounds me. To be that real-time, and having the world constantly changing. Wow. At least there are the separations of locations (world X can be this cluster of machines).

Now we get to Bigtable, the engine that Google built to scale in the cloud. Amazon has their new SimpleDB, and there are others.

What these guys are all doing, is revisiting the database story. Maybe it is time to think about if a RDBMS is the no-brainer choice.

When Google App Engine launched, I thought there would be a lot of people saying “oh man, I just want MySQL instead of this new thing”. I barely heard that, and instead heard more thoughts along the lines of “It is great to be able to use the scalable database that Google uses internally.” In fact, when you start using it and see that it is schema-less, you get a bit of a relief. You can build your model, and even use an Expando to be highly dynamic on the data in the backend. You go along your way, iterating on your code and model and you don’t have to spend time working on up and down migration methods. Doesn’t that remind you a little of the OODBMS dreams? But this time it is fast and scalable!

Resting on the Couch

With the interest in Bigtable via App Engine pushing thought, we also have CouchDB pushing from the other end. The end that says, what would a RESTful approach to a database be?

Apache CouchDB is a distributed, fault-tolerant and schema-free document-oriented database accessible via a RESTful HTTP/JSON API.

JSON built in. JavaScript right there. A database built for the Web?

It is great to see new ideas and thought about the storage of data. The RDBMS isn’t going anywhere of course. There are still a ton of tools out there for it and legacy code, and we all know that:

Data stays where it lies.

It is much easier to implement a new application talking to the old datastore, than migrate the datastore itself. It is like taking out the foundation. Also, SQL is getting new life in places too.

SQLite

I recently saw an application that used GWT on the client, and JavaScript on the server, which reminded me of my comic above. I wonder if we may end up with another flip, having SQL being used in the client, and other systems like CouchDB, Bigtable, etc being used in the enterprise / on the server.

It is happening on the client. SQLite seems to be everywhere. Your operating system, phone, browser, applications, everywhere. I bet I have around 20 SQLite engines on my system right now, and growing. Why is this happening? Well, instead of coming up with your own data format, parser, and search engine, why not just use SQLite and be done. It is very faster, perfect for single user mode, so everyone is a winner.

So, SQL has a looooong future ahead of it, but it will be interesting to see how the RDBMS weathers the latest storm.

Geoff Hendrey, of NextDB.net, emailed me discussing a similar issue and how he thinks that:

The database access issue is the "elephant in the room" as far as Ajax apps are concerned. It's a very hot topic, evolving rapidly, and related to cloud computing and DAAS (SimpleDB, LongJump, S3, Blist, NextDB.net, BigTable, etc).

Geoff is going to be at Web 2.0 Expo talking on the subject.

What are your thoughts on Ajax and the data tier?

ASIDE: I will be giving a joint talk with Ryan Stewart of Adobe there too, so come say hi, and ping me on Twitter with any thoughts.

Paul Irofti forwards us "an interesting article about bypassing stack protection in OpenBSD written by chris_fs on NewOrder. The article explains some theoretical concepts and provides the code to back them up mainly for testing and further exploration."

In recent years there has been a lot of focus on so called anti-exploit techniques being built into operating systems. These techniques come in a wide range of functionality but all with the same goal, to make the process of writing functional exploits harder, if not impossible. The general idea is that you will never be able to write 100% bugfree code so you have to make the process of exploiting these bugs harder. One of the operating systems that was among the first to incorporate some of these techniques and has probably also taken it the furthest is OpenBSD...

...In this article I will show you a theoretical scenario where these measures can be subverted, the scenario that is laid out is perhaps not very likely to exist in a realworld application (although not completely unheard of), and this article should be seen more as food for thought on the subject of circumventing anti-exploit techniques than a practically applicable technique.

Read the full article on NewOrder.