Microsoft fears Google Docs and other Google web apps, rightly so. Although I see OpenOffice as a much bigger problem for them, one that is gaining market share as we speak.

These products threaten the bigger of the two cash cows for Microsoft, its Office product. And one thing Microsoft knows, Google will continue to improve its products, until it gets there, and takes market share. Google apps tend to be well engined, fast, and the cost, well, I leave that up to you. But OpenOffice is free, and at version 3.0 now. And you can get OpenOffice for most platforms, Linux and Windows.

download a free copy today and try it out:
http://www.openoffice.org/

"Microsoft is not attacking Microsoft Office because doing so would increase Google's profitability, but rather it is doing so to damage Microsoft's focus and capability to attack the businesses Google really cares about," Kaihan asserts.

Makes no sense.

Did you (or Kaihan) mean "Google is not attacking ..." ?

Copyeditor???

--rj

@chips b malroy

"one that is gaining market share as we speak. "

Yup, literally as we speak:

Yesterday's download stats for Open Office 3.0.0

OpenOffice.org 3.0.0
139731 /?&product=OpenOffice.org&os=winwjre&lang=en-US&version=3.0.0
18469 /?product=OpenOffice.org&os=winwjre&lang=es&version=3.0.0
15315 /?product=OpenOffice.org&os=winwjre&lang=it&version=3.0.0
14876 /?product=OpenOffice.org&os=winwjre&lang=fr&version=3.0.0
11012 /?product=OpenOffice.org&os=winwjre&lang=ja&version=3.0.0
10037 /?product=OpenOffice.org&os=win&lang=pl&version=3.0.0
etc, etc, etc....
---------------
Total:
279806

All OpenOffice.org Versions
.....
---------------
Total:
324549

The killer in my opinion is perception. Because in IT most customers (including large corporate ones) either can't or won't think for themselves - let alone evaluate a product -, the perception of the company selling a product is everything.

Google is getting the perception of an unstoppable force - which is long term the biggest threat to Microsoft.

Another example is Apple, which is also starting to get the perception of an company that "just walzes into any markets" and takes them with ease.

Combined with Microsoft's perception fall-down from Longhorn delays and Vista, it no longer has the luxury of selling 2 versions of utter rubbish before making a workable version 3. Nor is it able to just announce an upcoming product to hold of purchasing and choke competitors.
...At least not as effectively as it used to.

In short, perception-wise Microsoft is starting to emanate the stench of hapless loser / bumbling geriatric.

I agree, and I think that Microsoft's best response is to attack Google on their only profitable turf which is Search. I mean how hard is it to come up with an indexing and ranking algorithm that matches Google's. No matter how brilliant Google's is, it's still doable. I don't know why Microsoft can't focus on this aspect.
If Google's profit from search falls down a bit, you'll see all these projects (like Chrome and others) shut down immediately. Microsoft can make a strong case to the users addressing their concerns about privacy when using Google's products but they gotta start by matching the quality of their search results.

Re. previous comment - to contrast that with the past. As some of us remember, there used to be a fear... yes real palatable honest-to-goodness fear of Microsoft.

Even as customers we were afraid.

One dared not even think about choosing anything but the Microsoft-standard back then for fear of terrible misfortunes arising as a result.

Back then when people thought about what the future of computing would hold it was essentially whatever Bill Gates said would be the "next paradigm shift" (eew, i puked a little just from typing that phrase) or whatever was in the Directions on Microsoft roadmaps.

It's easy not to notice such big changes until one really tries to think back about what things were like.

Memo to Microsoft...

You had a chance but you blew it. The comments preceding this have more wisdom in their few words than all the meeting minutes and emails any of your management has circulated over the past two years.

It's about time for the MSFT shareholders to do what anyone assessing decaying property value would logically do: begin developing an apportionment plan to divest losing assets and segmenting the property for value enhancement.

This is what any property holder should do and the shareholders have been remarkably patient.

You apparently need reminding your careers and company assets are shareholder property... not the other way around.

Maybe Microsoft is taking its time because it's *not* just about a response to Google Docs. It's more about taking a measured approach to bringing a half-billion Office users to the Web.

@Sean

Gee, ya think?

I would consider that an adequate answer if Microsoft had not wasted so much time playing chicken with an IP issue for four years.

Yours may have been an adequate answer three years ago when other companies were cautious about what they put out against Microsoft.

The answer may have been sufficient two years ago when Google was afraid to say they were working on a WebOS.

Heck, it might even have been a real nifty answer one year ago before Microsoft demonstrated their frantic realization the internet was for real and they didn't have a thing to wear to the party.

But, they tried to buy Yahoo and it appears they tried to buy Yahoo for the technology Yahoo most likely had earlier this year in their YOS - something more significant than Google's own "WebOS" wannabee Chrome and certainly not vaporware like Microsoft's promises to give developers something... again... one day.

But, here, have a hard disk crammed with FUD and fooey.

As the more pithy comments above relate, perception is the sole driver in marketing and the perception is Microsoft got lost in the swamp and they're burning a pile of money to light their way out.

I certainly do hope you're right, because, (heavens, here am I cavorting with mammon and filthy lucre) I'm now financially interested in Microsoft as a successful cloud participant partnership.

BUT, MSFT management has a very poor record reading the times and this particular disruption wave runs exponentially faster than any previous advancements.

Fortunately there will be other partnerships for me and mine, but, not necessarily for Microsoft given the number of enemies they've, ahem, "managed" to make.

Did you get the import? I trust most did.

I realize it's not about a response to Google docs. I don't consider Google docs a significant threat alone right now. BUT, I do consider Google docs as the free eyeglasses people all over the world are using to look at the Emperor in his fine new threads... and it's not a pretty sight.

I saw some glimpses of fine and flashy material at PDC and that spinster wiht the granny hair and granny glasses sure sounded like a fabric cutting fool, but I also heard Microsoft management try hard by proxy to justify their own past screwups by reprising the same old lock-in lectures.

It's when you can sew the pieces together that something becomes a suit. Until then, it's all empty cuttings.

Let's hope the fat old potentater will get some real clothing and make more of the correct decisions in the future than what he's done as a bumbling bicyclist through the bullpen so far.

Sounds like Microsost is trying to do what a small company called eXpresso is already doing. eXpresso allows users to share and collaborate on files in real time. They have not reinvented applications they actually use Microsoft excel. They also offer a plug in which allows users to edit in their desktop environment, and once they are done the changes are pushed to the online environment. eXpresso has only been around for about a year, but I hear they are making progress. The price to use it is very cheap compared to what Microsoft is going to charge. I dont know about you, but with the economy the way it is, every penny counts. Why pay more for something else when you can get it cheaper and it works just as good if not better! Oh ya, and its available now, not in the near future

Another serious threat to MS and Windows is Google's Web Toolkit (GWT). This is a development platform that produces very high quality rich web applications based entirely on open standards (no silverlight, flash, .net, windows, etc). It seems that all the new killer applications from many companies are being developed with this or something similar (not VS.Net). This is a completely viable development platform that allows you to deploy your web application on Windows, Linux and Mac web servers. It supports all the main browsers, requires no plug-ins and provides an incredibly rich experience. I think long term this is a real threat to Windows and MS.

@smist08

What you have in Google's Web Toolkit is Ajax and Java and that stuff is not a deterministic set of distributed transaction processors. Thus, you're asking for real trouble building any kind of scaled business process software using Ajax and Java.

Come back to the web application business when you hobbyists have grown up and you have something that won't break when you pop-rivet it into a real transactional process.

Want some background on Ajax? Sure you do.

Once upon a wonderful November day in 2004, Mark Lucovsky (Microsoft's web operating systems guru) went to Steve Ballmer (we know who that muffin top is) and said, (I paraphrase) "Stevo, you're not going anywhere with XML because you've already started pulling up all the projects Bill (Gates) bragged about as us owning XML so I'm leaving."

"LEAVING??!!" Ballmer answered calmly.

As a chair sailed past Mark's head, he said, "Yes, Steverino, I'm leaving you for Google." and he walked out through the hole the chair made in the sheetrock.

Of course, he ended up in the zen garden outside Steve's office, but somehow he managed to make it back into the building and stuck around to about February of 2005 (must have had to clean out his desk and such). Anyway he somehow, along the way out of the Microsoft campus, managed to walk out with something called XMLhttpRequest and the knowledge he had acquired working with that wunderkind in Microsoft stuck to the bottom of his shoe.

I say "stuck" because no way would Mark do something like take technology that didn't belong to him... I don't think...

But, anyway, it must have been real important because when Lucovsky finally started work with Google in February of 2005, Google suddenly came up with this amazing ability to transfer XML asynchronously between web pages and web servers without having to refresh HTML.

What a wonderful thing Microsoft's brand of XMLhttpRequest seemed to be. Like Magic! In fact, some were so enthusiastic they gave it a name that stuck as well: They called it "AJAX"!

Groovy.

That was clever and all because it kind of seemed to stick a knife in what Microsoft called SOAP. Now, you would think Microsoft would be really pissed about such a turn of events and all but, the odd thing is, Microsoft never said a word. Not one peep. In fact, most Microsoftists to this day act like they never heard of the thing.

It actually turns out to be about as useful as SOAP but more coarse and much more foamy and that's the problem. Remember Ballmer said he would "(expletive deleted) kill Google"? Well, passive aggressive Steve couldn't have known how it would work out but he did have his way, pretty much. Lucovsky brought that puppy right over to Google and Google went gaagaa and committed themselves to the AJaX puppy wholeheartedly and got heartworms from it.

How? It doesn't work the way Microsoft had hoped it would and they found out the hard way.

Everybody had some big parties and everybody thought they discovered the holy grail and they even built an industry around the thing and they even made a neato torpedo toolkit and they called it the Google Web Toolkit... and they had a party with their clients who were amazed a browser could actually look like it worked like a desktop (aren't looks deceiving sometimes?) and open-source has been whooping it up and spending project moneys like crazy in their brand new businesses...

Far out and cool, like. Far out.

Only one weird problem.

XMLhttpRequest, as Microsoft found sadly enough, is one dimensional and very lacking in features necessary to use as a messaging element for building deterministic distributed processors.

That's a lot of fancy words to say AJAX doesn't have true grit.

Oh, it's great for things like making user interfaces work faster as though they're on a desktop even when they're on a browser, but, there's no real way for the server or the client to be sure the last state of the distributed components done in Ajax are what they're supposed to be - not without a whole lot of headaches and processing overhead.

Try it. You'll hate it.

So, nobody in their right mind would actually build what they would contend would amount to a Web-based operating system with this thing... this thing with XMLhttpRequest at the center... because the WebOS you built like that would be a blind idiot like the first MSDos machines Microsofty made before NT. And that's dangerous when your network isn't your garage but open to the world at large.

Anywho, there's a background to the attempts Microsoft made to use this thing (that Lucovsky landed in Google with) as a distributed messaging framework and the whole story can be found in a little Microsoft component called SilkRoute. Neato name, but, unlike the real Silkroute trading between the West and the East way back when, this SilkRoute was only uni-directional with no feedback for determinism.

Thus, when Microsoft finally realized what it took to build a real WebOS, and they finally realized they didn't own the actual IP necessary to do the bi-directional determinism in transformation and transaction processing they thought they could use to build the WebOS that was to become Vista, they ended up having their real revenge on Google by not checking the bottom of Lucovsky's shoes when he walked out the Microsoft doors.

Oh fickled Fate, thou art sinister and persnickety.

Now? Three years later? Now, Google has a real fancy do-nothing do-hickey that might work well for advertising in electronic magazines because nobody cares the hell whether an advertisement gets your destination mixed up with the next person to wander across your dynamically allocated IP address. But, you sure as hell wouldn't want to do your bank account on something like that.

I know you people only skim across long posts so I love it when people think they've read the whole story but forget to check the last few paragraphs.

Microsoft's SilkRoute was used to fight some IP that was truly XML messaging based (heck, it turns out to be XML through and through) and thoroughly deterministic... In fact, you could actually use the thing to recreate a web-based distributed version of TPF aka Transactional Process Facility - the elemental components used to build the venerable IBM360 Mainframe operating system.

In fact, you could use such a system, if you wanted to, and build a virtual IBM360 mainframe operating system using thousands (heck, millions, if you needed) of fully qualified and bulletproof transaction nodes on a mass of distributed desktops and mobile computers interconnected and interoperated on the web.

No THAT's a whooopy.

Funny thing, the little bastard was a micro-kernel-web-server/client-agent around 400kb in size and cute as a button... whereas AJAX had trouble acting like a real button.

Now, isn't it fascinating that, here and today, Microsoft is claiming they're going to build Windows 7 out of a "kernel" called "Minwin" that's 26MB in size. Kind of like a whole cob up the poop-pipe when a tiny kernel would be much more comfortable.

So, Google Web Toolkit? I don't think so, smist08. It might be good for building things you don't mind losing, getting trashed or having some pilfering bandit duplicate and redirect, but, to my mind, I would certainly rather trust something that can actually perform actual computation at the local node if I'm going to be doing distributed applications, instead of risking my corporate IT career on something that will break when you try to scale it up to the real world.

You say you "...think long term this is a real threat to Windows and MS." You need to do a bit of studying before you bet the farm on that thought. If AJAX were a real threat, Google would have rolled out something more significantly like a real WebOS than Chrome. They've had three years to do so and they've had the chief windows-on-the-web guru working for them specifically (Google thought) to do just that. And it simply has not happened, has it? No. It hasn't.

You see, there's a IP issue standing in the way of AHJAX ever becoming something more than a SOAP opera stand-in. I'm frowned upon if I talk about it here so, sorry I can't hep you out there. But, if you do a little snooping, it's easy enough to find. I just wanted to give you a heads up because you sound so fresh, honest and eager and you sound like an Ajax true believer. Maybe you can become a real world advocate and take the message to your open-source colleagues who are likewise uninformed.

We'll see.

Anyway; The moral of this story is, if you're a real smart guy, don't take something that doesn't belong to you or you'll end up looking like an idiot.

I know it doesn't seem like much to have mucked through this whole post to be told but it's much more important than you can possibly know at this time in your burgeoning career in web applications. It was intended to help you and I hope it's taken that way.

I know it was painful getting here, but you now know so much more than you knew before... or, you at least have the opportunity to know more. There's no guarantee you'll take that opportunity... and I don't have a deterministic way to check your resulting status... like AJAX.

portuno_diamo - please do not mistake all people reading this website as mere backyard garage IT boys.

As for a WebOS - who wants or needs a WebOS? What would be the definition of a WebOS? Why would i want another OS??

All i want is to forget about the messy concepts and inconsistent UIs and conventions that the various OSes bring and just get to the fun bit of using the functionality on the web or the data i keep there.

Maybe I'm misunderstanding what's meant by WebOS - could someone enlighten me? TIA

@protuno_diamo, where do you get this information that XMLHttpRequest was coined in 2005? And what do you mean by "one dimensional"?

What portuno_diamo seems to be describing was first seen in QNX, first release in 1982. It was a tiny message-passing network-enabled kernel. And it was a lot smaller than 400KB, too.

But that statement is too short, too clear, too precise, too accurate, and hints of prior art that would invalidate any patents on distributed transaction processing that were issued several decades later.

And XML is derived from SGML as a simplified human-friendly form of SGML. Nobody owns the rights to XML. No matter how hard they try to claim such a thing.

Not sure what the other flowery B.S. is saying, other that something about poopy puppies giving heartworms to muffin topped deterministic bastards. Or was that poopy topped bastard muffins with deterministic heartworms? I can never keep all that meaningless gobbleygook straight.

@Gerardo Tasistro:
Look at this article from Apple to know where XMLHttpRequest came from:
http://developer.apple.com/internet/webcontent/xmlhttpreq.html

@whatever

That's the same question the mainframe builders asked when "personal computers" came on the scene.

The need and facility and usefulness of a true WebOS (and you'll be surprised at a true WebOS description - it's much different than most will preconceive) is undeniable when the need for greater portability, greater security, greater efficiency and greater productivity are seen in example use cases.

I have such a description that can be posted but the resulting text is very large and I tend to ramble anyway.

There's so much that can be said to answer your questions, I don't really know where to stop.

I do know where to start, however, and an optimized WebOS would begin by rendering all machines within a community as bare metal machines with attending agents assuming the local machine OS duties on an as-needed component basis.

If you can imagine that, you then have a picture of all local IT skills and requirements eradicated and all deployment, maintenance, management and governance of the machine done by WebOS functions whether automated services or socialize community members. All this is a functional part of a WebOS where it is all segmented and unconnected in a traditional OS performance.

There are many concepts to be decried by the traditional software proponents who believe there can be no improvement on present day technologies.

But, if that view is true, the software industry is at a dying point where the return on investment and effort exponentially deteriorates.

A WebOS community will rely on automated deployment by service and user selection, management by community policy and socialized contact, maintenance and troubleshooting by automation and remote socialized service and governance by corporate/cultural policy.

User resource allotment would be as a part of human resources management which is why a human resources platform is an ideal entry point for the WebOS concept... and not IT as most would assume.

As an aside, reduction and replacement of on-premise IT personnel of all kinds is a primary aim. A local hardware service would be one of the only on-site personnel necessary.

Again, a real WebOS is not going to be software "running on the web", as some say, because the web is an interconnected network of machines.

The software will be running in distributed fashion using the web as a connection for interoperation, data and application transport and
delivery of all servies to and from each client.

With each set of tasks and resources placed local or remote, as a service or as an application and, in the most optimized view, agents running on bare metal act as the abstraction layer previously occupied by the machine dependent OS.

Where a monolithic desktop OS is constrained to control and monitor resources at the local machine, a key feature of a WebOS is optimization of resource availability and performance where ever such resource facility would be desired or best allocated.

That said, there are many use case examples and architectural descriptions. I don't yet know what would be most useful to advance your understanding.

@Gerardo Tasistro

I did not say that. I said AJAX was coined in 2005 and it results from work Mark Lucovsky did with XMLhttpRequest. XMLhttpRequest had been around for a long time and it was part of Microsoft's search for a useful distributed processing component.

AJAX is "one dimensional" because it does not serve the needs of a true transactional processing component. It is therefore not an elegant solution
to the need for distributed agent processors.

@philosopher

I long ago stopped caring what level of "flowery language" stopped people from digging. It serves the purpose and those who will put out the effort will know what they see.

Just as you came to a realization in our conversation about community based WebOS, others learn by accident.

I leave that to them and I ignore complaints and characterizations.

The part of GWT that I like is that you can write the JavaScript part that runs in the Browser in Java and develop and debug it with real tools. For better client to server communications I don't use the mechanism built into GWT, but instead use general REST web services calls (with GData). These then solve all the problems you mentioned and make a fully scalable system. Then on the server the whole thing can be implemented easily with JavaEE which is quite robust (certainly more so than ASP.Net). A WebOS (ie Azure) is only needed by MS because Windows isn't currently good enough to do the job. In the rest of the world, Linux has been up to the task for many years.

@protuno_diamo, under that criteria couldn't we then label web pages as "one dimensional" and thus unable to serve the needs of true transactional processing. After all XMLHttpRequest is just XML over HTTP, the transport. The processing can be delegated to the server who has full support for transactions. In such a scenario AJAX becomes a form of RPC. Calling processes on the server which are completed or not and if not rolled back. Sure the communication between the browser and server can break down or the browser even crash, but that could happen with any common html page too. Couldn't it? We shouldn't be banking online then.

In regards to your comments on a WebOS I kindly disagree. To me the WebOS you mention looks like a cluster more than a WebOS. Maybe a cluster geographically scattered, but still a cluster. For me a WebOS is one the client PC/devices are also part of. In other words a grid. A term I didn't want to use to describe the "geographically scattered cluster" (although applicable).

Now if Azure were this type of grid I mention then it would be really cool. I could build my .NET application and deploy it locally on my home PC and have it available through the Azure grid.

You might question the feasibility of this as of course load could kill my home PC and home connection, but we are talking about a WebOS. The point being I install this application (which need not be a web/html application at all) in my home PC and it becomes available in the whole world because my home pc is part of a WebOS. Isn't that the point of a WebOS?

Think about it for a second. The function of an OS is to manage the computers resources for the user. In particular the logged in user. Do you know what hard drive sectors got used when you installed your most recent application? Nope, so you shouldn't worry about were the application you just installed in the WebOS actually resides.

If the "computer" is the web (a grid) then the function of the WebOS is to manage the available grid resources for the user. So I should have the same experience and hold the same configuration and settings across the web regardless of what particular PC or device I'm using. Now that's a WebOS, Azure is a glorified clustered hosting service.

@Gerardo Tasistro:
Absolutely correct.

And wasn't it Sun who said, a very long time ago in fact, that "the network is the computer"? And then backed it up with distributed computing implementations of that idea.

@gerardo

Don't you consider HTML unable to serve the needs of true transactional processing? You should, based on your words.

You end up moving the transaction away from the local control and "processing can be delegated to the server who has full support for transactions".

Well, you just proved my point. True transactional processing must be accomplished at the point local to the user. RPC is a server/client method that depends on remote processing... not the local processing demanded by those who claim a WebOS is "dangerous".

" For me a WebOS is one the client PC/devices are also part of."

Did you even bother to read what I wrote? The local machine (no matter what the size) in a true WebOS is KING, not an idiot terminal connected to a server somewhere as AJAX demands.

What you describe in the first part of your post is nothing more than centralized processing (not local) with user actuated transactions being sent to a remote server via RPC where the processing is done, then the user waits and hopes to see if the transaction processing happened.

You're describing what a mainframe does,but, in your description, you substitute the word "server" for mainframe.

"The point being I install this application (which need not be a web/html application at all) in my home PC and it becomes available in the whole world because my home pc is part of a WebOS. Isn't that the point of a WebOS?"

ABSOLUTELY. Thanks for the description. Now, imagine trying to do exactly what you're talking about doing with AJAX. Not gonna happen.

I agree with all your descriptions of what a real WebOS is. The kind of processing I am able to describe can accomplish all that. AJAX can not. Therefore I can map out WebOS with my method and you shot your own method in the head by depending on the remote procedure calls to a remote server to accomplish the transactions.

I agree Azure is far from a WebOS and that's troubling given MSFT has a license for true WebOS.

Puzzling.

@philosopher

Phil, do you really think Java has accomplished "distributed computing"? If so, where are the Java based WebOS gerardo describes? They never appeared and people have been trying to accomplish the WebOS since Java was born.

If you agree with what gerardo described in speaking about what a real WebOS does (and I do agree with his descriptions), would you not agree THAT is real distributed computing and the server/client lock-in Sun got us into is only a vague shadow of distributed computing?

Show us where HTML webpages are self-aware deterministic processing nodes in a web-distributed operating system. the webpage relies on requests for processing from a remote computer. It can't accomplish everything it needs to do by itself... thus, when the internet goes down, as Al is wont to say, your HTML page is dead as a bigmac.

Client/server is dumb-terminal/mainframe simply rebaked. "The network is the computer" is fine, if you can really distribute your processing power over that network. Keeping the processing power on a centralized server and forcing remote users to call for procedures to be run on the server and the results sent back is mainframe/terminal technology.

Amazing how just putting some new words on a pig makes the pig dance.

True distributed processing requires self-actuating agents local to the user machine that can perform the transaction processing ON-SITE, then offload the results of that processing to repositories for archival and audit trail.

Without that capability at the core, you're not distributed computing. You're remote computing.

@gerardo

AJAX can't even be set up to perform deterministic testing. How in the world do you think it's going to be able to pull off deterministic local processing in concert with interoperations with other clients, let alone with other servers?

http://www.css-faq.com/ajax/ajax-testing-–-facing-cross-browser-problem/

Again, client/server "webpages" has its place, but that's remote computing. AJAX is a UI element. It has no place in the critical phases of transaction processing.

Not distributed computing. You need a component that will stand in for the server local to the user.. not be completely dependent on the server while the user waits for an answer from remote procedures.

@portuno, first of all I'd like to clarify something about my point of view. I'm not trying to label something as local or remote. In the sense of a true WebOS it should not matter. It should be a seamless experience. Secondly the so called server can be a) a server farm not a single machine and b) reside locally on my machine.

Thus for me your requirement of "transactional processing must be accomplished at the point local to the user" is totally unnecessary. Actually it is more of hindrance. The actual point of these distributed systems (Azure and the WebOS concept) is that there be no privileged point of observation (or execution for that matter).

In other words I click the button and the operation is completed. Where? who cares. Local or remote is not an issue. It could be some of those local(web browser) storage systems begin promoted by Google, it could be a remote SQL server or FTP site for all I care. In that sense the local machine is neither "KING" nor "dumb terminal".

As a counter example we could take a GUI application. Your average off the shelf desktop app. A button on the screen does not hold in its code the means to do what it does. It (under best practices) calls a listener which when fired actually calls a piece of code (object) that does the actual work. Now neither the button nor the listener know if the object will run the process (transaction) locally or remote. For all it cares the object could be a proxy object and be doing some work remotely via a web service or just getting some info from a locally running thread (like some asynchronous data feed). Would you call it true transactional in one case and not in the other because it is using a remote resource rather than a local one? And if so then what is the point of being gridded? To me the point of being gridded is that accessing information in a locally running thread is equivalent to accessing information from a remote location. Because once gridded all elements become part of the "collective processor" so to speak. There is no border between local and remote. And yes probably I did express myself ambiguously when I used the word server a better term would have been resource.

So through AJAX you contact a resource capable of handling the process requested and communicating using HTTP. The resource could be running locally, on the same subnetwork, on the same country or across the world. So when you click on a button an operation is either completed fully or not at all. If to you AJAX can not satisfy the requirements of true transaction then how can classic html web page be any better after hitting the submit button? Or a .NET GUI application that while running locally uses Azure SQL storage remotely?

@portuno, you said "AJAX is a UI element. It has no place in the critical phases of transaction processing."

I believe this marks our difference. I don't see AJAX as a UI element, but a communication component. Build a request, send it and wait for an answer. Everything else around it is just plain JavaScript.

The problems presented by the link you post have been present in everyday GUI applications since multithreaded OSs exist. Actions that trigger various flows over different threads that at one point or another will return information that will update the UI (asynchronously) are new to HTML since the advent of AJAX. But common place in everyday desktop systems. The problems in the testing methods are related more to the maturity of the testing tools than the AJAX frameworks themselves.

@gerardo

Your definitions get stretched out of shape so you can fit your argument over your architecture.

Now, a remote server is "local"? Anytime you have to redefine words in your position to stay up, you have trouble in your architecture.

First, you have no choice but to deal with the remote or local issue; with AJAX, you must depend on remote procedures to be accomplished. If you have local resources, why are you using AJAX?

You attempt to say the processing resources triggered by your AJAX event are "local" even, but you adjust your argument by claiming anything on this planet is "local" as long as there's a network connection.

I'm not interested in dancing around words. We're supposed to be discussing actuality and not spin.

Actuating true local (meaning not over a breakable connection) resources are not part of the AJAX framework.

"Local or remote is not an issue."

Given questions on latency, interception, interruption, I really don't see how you can maintain that concept.

"In the sense of a true WebOS it should not matter. It should be a seamless experience."

So basically, you're just saying the GUI is what is distributed and all the processing power is "local" back at the mainframe, errr, server.

The "experience" can only be considered "seamless" if one can say in a deterministic way the transaction being carried out WILL be carried out and the only way to know that is to have as much of the processing required in the transaction carried out local to the event initiation.

Build a GUI with remote processing and you have nothing more than another webpage - which locks up and dies with the lost connection to the remote resources.

We can all argue the semantics of "local" and "remote" all day long but "it can be done this way" doesn't equate to "it should be e done this way".

My solution can place the processing power local to the user. Yours does not.

My solution will survive glitches in the interconnections. Yours will hope to survive.

My method is deterministic. Hope is not deterministic.

The present traditional realm will try to cobble as many solutions to "do the same thing" but, in the end, the result will be deterministic WebOS or not WebOS, no matter what one wants to "call" it.

@gerardo

"The problems presented by the link you post have been present in everyday GUI applications since multithreaded OSs exist."

PRECISELY. Thank you.

The solution I am advocating does not have that problem. The testing is deterministic just as the processing is deterministic.

This reminds me of what I sat through back in 1995 when IE and Netscape were fighting it out

My simple user problems are:-

1. Google chrome does not reply to any "hopefully" constructive suggestions - of course there are glitches with any beta stuff - I suppose, as a Joe the plumber chap - I do not speak their language because they are busy putting their own "buried" blocks on IE users when entering search engine? Well it is getting slower and slower!

2. Thus Microsoft has now (since loading chrome)done something to cause my computer to refuse to shut down, foisted a very limited "basic option" to my hotmail email and so on (and I do pay hotmail for the extra mile) - I feel they are petulantly "slapping my wrist"

My goodness history repeats itself - the war of the roses all over again

I give in - hands up - tomorrow I shall pop out and buy an apple and move to Bagdad where I understand the streets are safer - but... can anyone tell me if there is a user damaging fight going on out there in teh orchard? chrome should have been released - it is nice to try something new, but frustrating to be caned by teacher!
but then times are in general interseting anyway and I am glad I live in a time of free speech

@protuno

"Now, a remote server is "local"? Anytime you have to redefine words in your position to stay up, you have trouble in your architecture."

127.0.0.1 aka localhost rings a bell to me. A lot of applications support TCP/IP connections to resources even when such resources are local. And above that such applications are not built to lockup and die if a response doesn't return within a given time. They are robust, they recover and retry.

"First, you have no choice but to deal with the remote or local issue; with AJAX, you must depend on remote procedures to be accomplished. If you have local resources, why are you using AJAX?"

With AJAX I depend on procedures that are not residing in the browser, but that doesn't mean I don't have local resources. And even when I do I'm entitle do use AJAX as I see fit.

'"Local or remote is not an issue."

Given questions on latency, interception, interruption, I really don't see how you can maintain that concept.'

It is not an issue because the application must be robust enough to work properly regardless of latency, interception and interruption. It will not be able to complete its task, but it should not lock up and die.

So your application should work correctly regardless of its resources being local or remote. Because even local resources although less prone to latency and interruption are also finite. For example you will run out of heap space or run out of disk space if you abuse them. A properly build application must be robust enough to counter such issues and recover from them. Imagine if the testing of a word processor depends on what is typed. Or imagine if I built a Java application that depended on the proper garbage collection running at a given time. It is unconceivable. Yet I can build a robust multithreaded application that is properly tested without needing to explore all memory space states or possible event occurrence times.

"My solution can place the processing power local to the user. Yours does not."

Why do you believe so? My solution makes local and remote processing power available to the application. With the added benefit of not having to distinguish between them at developement/compile time. It is seamless for the developer and thus the application. Hence my statement "Local or remote is not an issue." I'm not disregarding latency, timeouts and disconnects. They are contemplated as part of the robustness of the application.

The resource that will resolve the "power need" will be determined at run time. It can be local or remote and the application is built robust enough to handle the problems you present.

This is the way a visualize Azure. Although the examples I've seen on the Microsoft site don't exemplify this fully (they're more oriented at how easy it is to do something) I believe this is the final goal. You can upload a web app that requires SQL storage. By using a set of defined rules or interfaces (probably in the sdk) you can access the information regardless of where this SQL processing takes place. It can be on the same machine your web app is running or on one across the globe. Latency, disconnection and the whole set of possible issues are properly handled by the application so it doesn't "lock up and die" if the response doesn't come back within 25ms (to say a number).

Also: Dan Kegel from Google is a Wine developer and was the Wine 1.0 release manager.

Wine is increasingly good at running Windows apps. Like, the five year old piece of crapware that you can't even find the developer for any more, let alone ask them to do a Linux version. Those odd little apps are the stuff that keeps businesses running one old Win98 box in a corner ... well, Wine runs them better than XP or Vista do.

We use Wine at work for precisely this purpose: running one Windows app essential to our work, but as just one process on a Linux box rather than running a whole extra Windows box. So anyone who claims Wine isn't ready for enterprise use is simply factually incorrect.

And Wine is already a better Windows than Vista.

Quote "Wine runs them better than XP or Vista do"
-
Although I havent used Wine much, Ive found it very good. Infact on the same machine that I used to have a Windows installation on Wine ran the software quicker than it did through native Windows.
-
Anyway, my point is, with every version of Windows come new backwards comp issues, I think the above statement is very true, and a quick look at the compatibility list of Wine reveals quite a few packages as working under it, that have been named as being incompatible with Vista.
-
What a strange world we live in. Linux able to run old Windows software better than Windows. Whatever next?
-
Oh and for anyone reading who doesnt know what Wine is (and Id hate for them to read a MS-shill post and be mislead or not to realize that you can run Windows software in Linux) Ill explain.
-
Wine is software that allows you to run Windows software through Linux. You do not need to have Windows installed, Wine is FREE, but its NOT an emulator.