You may not get the timing just right, what you think is going to take 2 years might take 5, but if you bet on Moore's Law you can be pretty sure your time will come. Look at the rise of interpreted languages, virtual-machines, etc. over the past decade. It's not an accident, it's just Moore's Law playing out.
Still, it's not just that machines can now run "AJAX" apps fast enough that limitations in the underlying technologies are marginalized, AJAX is rising again because we've yet to provide a compelling alternative that combines the speed of development, speed of deployment, speed of maintenance patches, speed of market corrections, speed of "virality" (word of mouth), etc. that are supported by using a browser as a deployment platform instead of limiting it to marking up a few physics papers.
When confronted by an enemy stronger (in this case 10x so in terms of market share) you do not attempt to out-muscle them. If you want to live you use their strengths against them.
What is M$'s biggest strength? Monopolistic power that allowed them to create a deployed base comprising 90% or more of all browsers. The question is how to turn that strength into a weakness not how to "out-sell" M$ and get Mozilla onto those desktops. Not that that would be a bad thing, I'd love to see Firefox everywhere;).
The real answer lies embedded in this comment, posted earlier:
Actually Microsoft was one of the few groups in favour of work like this at the recent workshop (they didn't want scripting involved, but apart from that were in favour with extending HTML rather than going down the XForms or other new language route).
Now why would M$ have problems with scripting? Simple -- they can't undo having shipped hundreds of millions of "JavaScript VMs" to the world. Those browsers are sitting there, just waiting for the right combination of JavaScript and XML to bring them alive -- and M$ knows it.
Sure, unvarnished JavaScript has a lot of warts, but it also has garbage collection, prototype-based inheritance, full closures, first-class functions, and a number of other powerful features.
If you treat JavaScript not as an "endpoint" but as a starting point you can build virtually anything you like. I know, I've been doing it for 5 years creating everything from full-blown OO to web service workflows in JS and am on the verge of shipping XForms support for IE6+ and Mozilla with no applets or plugins of any kind. This isn't theory, I've got running code.
The bottom line is we don't need a new VM (browser), we need to use the ones that are already out there to their maximum effect. Those IE6 installations could just as easily become a massive anchor holding back M$'s plans for.NET if the right JavaScript took advantage of them.
What's the best news? Our benchmarks show that the same JS/XML applications run at least 2X faster in Firefox, offering a compelling reason to migrate over time to Firefox running XForms and other W3 standards, not.NET.
The RPL (which is OSI approved) was specifically designed to support an open vs. closed model rather than the all-too-familiar "open unless you make money" game. It also closes the distribution loophole and provides a clearer definition of what code is covered.
Under the RPL, the scope of coverage is code YOU (organization or individual) write that's required to run any application containing RPL code. In essence, if a third party downloaded your application package and couldn't run it because it was missing code YOU wrote, you're in violation of the license. That being the case it reaches "across the wire" to encompass the application, without causing issues mixing in third-party code from other licenses.
The bottom line for the RPL is that if you derive value (through either use or distribution) you reciprocate either with your cash or your code. It's a question of returning fair value in whatever currency you have the most of, time or money.
I think it's the best example yet of the kind of licensing models we'll see in the future. When combined with a "traditional" commercial license it creates a powerful dual-licensing model that can support open source development by companies whose customers can't always open source their own products.
Just wondering why, when the topic of browsers as "cross platform platforms" is introduced, people immediately jump to the conclusion that the user would have to be running the one you targeted -- or that you have to be cross-browser?
In the context of this discussion that doesn't make sense to me. If you're building an app with Java, or C++, or any of the other technologies mentioned here you'd ship a complete package. If the user didn't have the libs/jars/etc. you required you'd include them in your installer.
Why not do the same with Mozilla? Just include it in your installer. It's your "XMLVM", providing portable cross-platform XML-programmable application support. It runs practically everywhere, its native programming model is XML-based. It has XSTL, SOAP, XML-RPC, etc. built in, all scriptable as needed using JS and XPCOM.
Within the context of "what can I put in my installer package that costs me nothing but gives me access to the most platforms with a single codebase" I think Mozilla wins hands down.
I've been the DBA for a company using SAP-DB as a bundled DB for the past 4 months. Let me outline the major reasons I'll avoid it in the future.
One, in the first week I was there my machine crashed. When it came back up the SAP database was corrupted. The PostgreSQL database running on the same box came back up fine. Not my idea of how a database should work.
Two, the command line sucks. This is a real problem for administrators and developers trying to understand how their queries are going to run. Every SQL query you want to run has to be prefaced with sql_execute and there's no multi-line buffer support. Putting a semi-colon on the end of your query (which is standard practice in Oracle or PG) causes a syntax error. Frustrating as hell.
Three, programmability is pathetic. No before triggers, only after triggers. No docs whatsoever on the procedural language extentions that would mirror PL/SQL or PL/pgSQL for example. Actually, they're there, but buried in the Reference Manual along with all the other SQL commands so you have a hell of a time getting your head into it. Some might say putting logic in the database is a design flaw. I have two words for you: "Oracle Financials". Billions in revenue from an application written almost entirely in stored procs. Encapsulation is a joke if you think it means putting logic in your Java. It's only going to protect data shared across applications properly when it's inside the DB in the form of rules, triggers, constraints, etc. First time someone calls up DBVisualizer or something and screws your data you'll understand. Scalability can come from distributed database instances just as easily as it comes from bloated application servers.
Four, no support now, nor any planned for making external calls ala Oracle or PostgreSQL so you can have triggers/procedures call programs outside the database etc. Think about all the noise about Message-Oriented-Middleware and then imagine that your database triggers could simply call external procs. Now put a trigger on your shipment table so that any time a shipment is updated it calls an external proc to email the parties involved in the shipment a status update. Saves a hell of a lot of code to encapsulate that at the DB since you *know* it can't be called unless the data was successfully updated. But you'll never be able to do it in SAPDB. Both Oracle and PostgreSQL support this today.
Five, creation, management, and maintenance are 10x what they are for PostgreSQL. You have to spend a lot of time trying to figure out what parameters to use for your database creation. Then you have to spend a lot of time watching over devspace allocations or you'll wake up to find the database hung cause you had somebody fill up the logspace. Same problem can happen on PG if you fill up the disk, but you probably already have sysad jobs checking for that in a production environment anyway.
Six, support is available if you think waiting for the folks in Germany to wake up and respond to your email is "timely". I don't. Meanwhile the PostgreSQL development team never seems to sleep. Those guys are always online, and always ready to respond to well stated questions.
In summary, I recently had to propose a database to one of my clients moving a 24x7 shop off of Oracle8i. I said PostgreSQL because it a) didn't corrupt data, b) had serious docs and 5 separate books out (of which you have to purchase at least two to get full coverage but at least they exist), c) had tools that were easily accessible and UNIX-friendly, d) was a breeze to administer, and e) had an active developer community that was 100x the size of the SAP community in case we needed help.
Slashdot Mirror
http://www.nytimes.com/2009/06/18/fashion/18skin.html?_r=1
You may not get the timing just right, what you think is going to take 2 years might take 5, but if you bet on Moore's Law you can be pretty sure your time will come. Look at the rise of interpreted languages, virtual-machines, etc. over the past decade. It's not an accident, it's just Moore's Law playing out.
Still, it's not just that machines can now run "AJAX" apps fast enough that limitations in the underlying technologies are marginalized, AJAX is rising again because we've yet to provide a compelling alternative that combines the speed of development, speed of deployment, speed of maintenance patches, speed of market corrections, speed of "virality" (word of mouth), etc. that are supported by using a browser as a deployment platform instead of limiting it to marking up a few physics papers.
When confronted by an enemy stronger (in this case 10x so in terms of market share) you do not attempt to out-muscle them. If you want to live you use their strengths against them.
;).
.NET if the right JavaScript took advantage of them.
.NET.
What is M$'s biggest strength? Monopolistic power that allowed them to create a deployed base comprising 90% or more of all browsers. The question is how to turn that strength into a weakness not how to "out-sell" M$ and get Mozilla onto those desktops. Not that that would be a bad thing, I'd love to see Firefox everywhere
The real answer lies embedded in this comment, posted earlier:
Actually Microsoft was one of the few groups in favour of work like this at the recent workshop (they didn't want scripting involved, but apart from that were in favour with extending HTML rather than going down the XForms or other new language route).
Now why would M$ have problems with scripting? Simple -- they can't undo having shipped hundreds of millions of "JavaScript VMs" to the world. Those browsers are sitting there, just waiting for the right combination of JavaScript and XML to bring them alive -- and M$ knows it.
Sure, unvarnished JavaScript has a lot of warts, but it also has garbage collection, prototype-based inheritance, full closures, first-class functions, and a number of other powerful features.
If you treat JavaScript not as an "endpoint" but as a starting point you can build virtually anything you like. I know, I've been doing it for 5 years creating everything from full-blown OO to web service workflows in JS and am on the verge of shipping XForms support for IE6+ and Mozilla with no applets or plugins of any kind. This isn't theory, I've got running code.
The bottom line is we don't need a new VM (browser), we need to use the ones that are already out there to their maximum effect. Those IE6 installations could just as easily become a massive anchor holding back M$'s plans for
What's the best news? Our benchmarks show that the same JS/XML applications run at least 2X faster in Firefox, offering a compelling reason to migrate over time to Firefox running XForms and other W3 standards, not
The RPL (which is OSI approved) was specifically designed to support an open vs. closed model rather than the all-too-familiar "open unless you make money" game. It also closes the distribution loophole and provides a clearer definition of what code is covered.
Under the RPL, the scope of coverage is code YOU (organization or individual) write that's required to run any application containing RPL code. In essence, if a third party downloaded your application package and couldn't run it because it was missing code YOU wrote, you're in violation of the license. That being the case it reaches "across the wire" to encompass the application, without causing issues mixing in third-party code from other licenses.
The bottom line for the RPL is that if you derive value (through either use or distribution) you reciprocate either with your cash or your code. It's a question of returning fair value in whatever currency you have the most of, time or money.
I think it's the best example yet of the kind of licensing models we'll see in the future. When combined with a "traditional" commercial license it creates a powerful dual-licensing model that can support open source development by companies whose customers can't always open source their own products.
See http://www.opensource.org/licenses/rpl.php
Just wondering why, when the topic of browsers as "cross platform platforms" is introduced, people immediately jump to the conclusion that the user would have to be running the one you targeted -- or that you have to be cross-browser?
In the context of this discussion that doesn't make sense to me. If you're building an app with Java, or C++, or any of the other technologies mentioned here you'd ship a complete package. If the user didn't have the libs/jars/etc. you required you'd include them in your installer.
Why not do the same with Mozilla? Just include it in your installer. It's your "XMLVM", providing portable cross-platform XML-programmable application support. It runs practically everywhere, its native programming model is XML-based. It has XSTL, SOAP, XML-RPC, etc. built in, all scriptable as needed using JS and XPCOM.
Within the context of "what can I put in my installer package that costs me nothing but gives me access to the most platforms with a single codebase" I think Mozilla wins hands down.
I've been the DBA for a company using SAP-DB as a bundled DB for the past 4 months. Let me outline the major reasons I'll avoid it in the future.
One, in the first week I was there my machine crashed. When it came back up the SAP database was corrupted. The PostgreSQL database running on the same box came back up fine. Not my idea of how a database should work.
Two, the command line sucks. This is a real problem for administrators and developers trying to understand how their queries are going to run. Every SQL query you want to run has to be prefaced with sql_execute and there's no multi-line buffer support. Putting a semi-colon on the end of your query (which is standard practice in Oracle or PG) causes a syntax error. Frustrating as hell.
Three, programmability is pathetic. No before triggers, only after triggers. No docs whatsoever on the procedural language extentions that would mirror PL/SQL or PL/pgSQL for example. Actually, they're there, but buried in the Reference Manual along with all the other SQL commands so you have a hell of a time getting your head into it. Some might say putting logic in the database is a design flaw. I have two words for you: "Oracle Financials". Billions in revenue from an application written almost entirely in stored procs. Encapsulation is a joke if you think it means putting logic in your Java. It's only going to protect data shared across applications properly when it's inside the DB in the form of rules, triggers, constraints, etc. First time someone calls up DBVisualizer or something and screws your data you'll understand. Scalability can come from distributed database instances just as easily as it comes from bloated application servers.
Four, no support now, nor any planned for making external calls ala Oracle or PostgreSQL so you can have triggers/procedures call programs outside the database etc. Think about all the noise about Message-Oriented-Middleware and then imagine that your database triggers could simply call external procs. Now put a trigger on your shipment table so that any time a shipment is updated it calls an external proc to email the parties involved in the shipment a status update. Saves a hell of a lot of code to encapsulate that at the DB since you *know* it can't be called unless the data was successfully updated. But you'll never be able to do it in SAPDB. Both Oracle and PostgreSQL support this today.
Five, creation, management, and maintenance are 10x what they are for PostgreSQL. You have to spend a lot of time trying to figure out what parameters to use for your database creation. Then you have to spend a lot of time watching over devspace allocations or you'll wake up to find the database hung cause you had somebody fill up the logspace. Same problem can happen on PG if you fill up the disk, but you probably already have sysad jobs checking for that in a production environment anyway.
Six, support is available if you think waiting for the folks in Germany to wake up and respond to your email is "timely". I don't. Meanwhile the PostgreSQL development team never seems to sleep. Those guys are always online, and always ready to respond to well stated questions.
In summary, I recently had to propose a database to one of my clients moving a 24x7 shop off of Oracle8i. I said PostgreSQL because it a) didn't corrupt data, b) had serious docs and 5 separate books out (of which you have to purchase at least two to get full coverage but at least they exist), c) had tools that were easily accessible and UNIX-friendly, d) was a breeze to administer, and e) had an active developer community that was 100x the size of the SAP community in case we needed help.
Why not SAPDB? More accurate to ask Why In Hell?
ss