Skip to main content

Posts

Showing posts from April, 2004

Brower based apps and Longhorn

Adam Bosworth writes about browser based apps on his blog. Here is my response.


You caution the world on possbility of Microsoft taking the applications back to the desktop away from the browser. I feel your argument is as valid as some hardware designed skimping of memory because in the old days memory was expensive.

The compelling reason for deploying browser based applications was that such applications are cheaper and easier to maintain thereby saving the enterprise money etc. That was the desktop centric argument. Then came mobile computing and that reasoning was further strengthened because we now have multiplicity of devices.

Those compelling reasons are no longer valid in today's world of falling cost of semi-conductors, software and services i.e. global deflation.

The clients side mobile or desktop is getting richer, cheaper and ubiquitous without sacrificing variety. If the application is not able to exploit this, the application is not worthy of deployment. While you m…

Jini and Jxta and Grid Services

So I keep getting asked why not use Jini for grid discovery and Jxta for network independence in grids. Most of the folks who asks actually are not able to tell me what is the distinction between Jini and Jxta. Anybody have a real simple way of explaining? I will give it a try below

Jini is a technology for communication in a distributed computing environment. At the time it was formulated, platform independence was all the craze and thus Jini was born to essentially make RPC platform dependent. But like Java platform it is dependent on the Java language. Like RPC, I believe Jini's communication model is synchronous. The new JavaSpaces builds on top to give a shared memory asynchronous model for communication.

Jxta is a technology for extending distributed computing across a WAN which by definition is heterogeneous. Therefore Jxta involves network protocol routing and is based on asynchronous communication. The problem I see is that it does not use existing IP infrastructure for a…

.NET getting complex

The more I see Microsoft and its .NET today, the more I am reminded of Sun during the early days of Java.

Not a week goes by that Microsoft and its .NET team don't announce a great new WS_* standard or a library or platform for .NET. Just like the early days of Java most of the stuff is quite complex and more likely to be preached by evangelists rather than implemented by developers. Portions of Java that were widely adopted are a very small subset of all the packages that one has to download to get the SDK. I feel the same fate is destined for .NET. Eventually, it will become another souped up web server with server side application execution technology (Java's Servlet). Of course, there will be lots of books, mugs, t-shirts and those pesky evangelists.


I wonder when the .NET balloon deflates, we will hear their CEO harp on their cash position too ;)

Brower based apps and Longhorn

Adam Bosworth writes about browser based apps on his blog. Here is my response.


You caution the world on possbility of Microsoft taking the applications back to the desktop away from the browser. I feel your argument is as valid as some hardware designed skimping of memory because in the old days memory was expensive.

The compelling reason for deploying browser based applications was that such applications are cheaper and easier to maintain thereby saving the enterprise money etc. That was the desktop centric argument. Then came mobile computing and that reasoning was further strengthened because we now have multiplicity of devices.

Those compelling reasons are no longer valid in today's world of falling cost of semi-conductors, software and services i.e. global deflation.

The clients side mobile or desktop is getting richer, cheaper and ubiquitous without sacrificing variety. If the application is not able to exploit this, the application is not worthy of deployment. While you m…

Redhat Free?

So if you do up2date on Redhat, you have to pay $20 for a yearly subscription. I thought Redhat was free?

Even Microsoft does not charge for a windows update!

May be Sun should charge charging for those Java updates..

.NET and J2EE Interoperability

So I found this company mainsoft at http://www.mainsoft.com. It offers this toolkit which allows you to develop applications on VS.NET for J2EE.

You think MSFT and SUNW made a deal to put mainsoft out of business ? ;)


Java Community Fragmentation

Java community's fragmentation will lead to .NET taking over the developer mindshare and skillshare.

These marketing guys don't know much about marketing to developer world. It is not marketshare or mindshare that matters. What matters is skillshare. .NET through its VS 2005 or whatever they are going to call Widbey will enable a 60% of the programmers out there to enter the world of webservices. Only about 20% of the programmers in the world are Java programmers.

The response from Java community is further fragmentation of Java. Visual Cafe, JBuilder, JDeveloper, Sun Studio and Eclipse. And they say Java should remain in JCP to prevent fragmentation. IDEs have already fragmented the Java community.