Posted
by
samzenpuson Wednesday May 30, 2007 @11:34PM
from the google-google-google dept.

Mister Inbetween writes "Google is rolling out a technology designed to overcome the major drawback faced by all web-based applications: the fact that they don't work without an internet connection. Google Gears is an open source technology for creating offline web applications that is being launched today at Google's annual Developer Day gatherings around the world."

There are some sample applications available here [google.com] to help you get started using Google Gears. I found it pretty non-intuitive at the beginning but I think I'm starting to get the hang of it slowly.

I think it's just an attempt at accomplishing that (in)famous goal: "write once, run everywhere". Many have tried it before. XAML, GTK+Glade, Java, Flash, XUL are just some examples.I frankly don't know what Google is trying to accomplish, unless it's just a random jab at Microsoft's Office suite, meant purely to keep Microsoft on its toes (Office being their bread and butter).

Other than that... I honestly don't get it. The Web is the closest anyone has ever got to a universal platform so far, and here they

At Google we recognize that this is a serious problem for you slashdotters: article summaries frequently omit any link to the webpage in question. But not to worry: we've got engineers hard at work on a new technology that will allow anybody to search for pages on the web.

You might as well create your own traditional app so that you don't have to deal with compatibility and security issues with a multitude of browsers and platforms. Or maybe the idea is doing something completely opposite to what Microsoft has been doing for almost a decade now, putting the browser functionality within the app.

Web applications are inherently cross-platform-- the OS doesn't matter, only the browser. Also, they don't really require that you install anything or have admin privileges to install things, and they're accessible from any computer with an internet connection and web browser.

The downside of web apps is that you can't take them with you. Unplug from the network and you can't use them. I guess this might be a good step towards solving that problem.

Of course, whether this should all be built into web browsers, which were originally intended to store static pages, is an issue you could debate. Sometimes I think it might make more sense to make a browser-like framework for programs, but built from the ground up for applications instead of static pages. But then, I guess that more and more, that's what browsers are becoming.

So the problem is we have, what? 3 OS platforms, and 5 or 6 browsers. Seems just as easy to create apps to run on the 3 OS platforms than even the 4 major browsers. If the idea is web-hosted applications and files, sure the browser based app could make sense.
I guess the solution is we all use Firefox for offline web apps, that way we trust Google to create the foundation for the application, ultimately the "OS within the browser" to run apps on. Why bother using the browser as a platform when you don't

Why not just create a basic virtual machine client and load it with this fast, simple "Google OS"? The capabilities would be similar - it needs access to the local file system to store documents, and the app would run in a highly stable evironment that needs to do nothing but run apps.

Dude, I think you just described Java.;-)

I hear Java Web Start even solves the problem of distributing app updates seamlessly. Not that I am a fan of Java for GUI apps as far as look and feel go, but it certainly meets to your requirements for a virtual machine and I'd probably take it over some of the HTML + JS shite that is out there.

Why is it that nobody can see that what everyone longs for was invented more than a decade ago. It is like the 900 gorilla in the room that nobody wants to talk about.

Why yes, javascript is slow. But it's moe than fast enough for web apps, which tend not to require massive computation or even all that much UI candy. The vast majority of the rendering/UI/storage work is done by the browser (very fast machine-specific application) and the webserver (high-powered multi-core server farm), which means that javascript is free to chug away at whatever tasks it is given.If google released their apps as bytecode-compiled java, they would *lose* actual CPU performance in order t

3 OSes? WTF? Let me guess, Windows, Mac OS and Linux. Well you forget Mac OS X has intel and ppc to support. Microsoft has differences between Windows versions. An app for XP might not run in Vista x64 for instance. Linux distros are not standardized enough. You can't count on all the libraries to be present or GTK or QT to be a specific version. Then you might have users on BSDs, Solaris, ecomstation, ReactOS, BeOS, OS/2, or some other crazy thing. PDAs have different systems as do cell phones. G

Of course, whether this should all be built into web browsers, which were originally intended to store static pages, is an issue you could debate. Sometimes I think it might make more sense to make a browser-like framework for programs, but built from the ground up for applications instead of static pages. But then, I guess that more and more, that's what browsers are becoming.

You may want to check Adobe Apollo, a multi-platform runtime that allows you to create desktop apps based on: HTML/CSS/JS and Flash.

It has ability to store/read data locally and basically act as a normal desktop app, but it's inherently multiplatform, because it uses platform neutral technologies (even more so than Java and.NET managed to do so far).

Honestly I'm not sure how smart it would be to invest in Google Gears. You may want to deploy a Yahoo app.. and then what? Google's also known for their ton of search-unrelated projects which they abandon the next day.

For Adobe, Flash and Apollo is a deal maker/breaker: if they don't get it right, Microsoft and WPF/.NET/XPF/Expression will simply throw them out of business.

It has ability to store/read data locally and basically act as a normal desktop app, but it's inherently multiplatform, because it uses platform neutral technologies (even more so than Java and.NET managed to do so far).

First of all,.NET was NEVER intended to be platform neutral. There's Mono, sure, but last I checked Microsoft is giving that project little or no help. Java is actually pretty good as far as cross-platform goes. I'm not a Java developer myself, but from what I understand Java developers

Given a decent language like Java, why would anyone WANT to develop their apps in... Flash. Yuck.

-matthew

It's funny isn't it. First of all, tools. It's about rich media, and Java has only dveleopment tools. Where's the rich media/interactive capabilities? Second, Flash takes a lot less resources than Java and is a lot smaller than Java.

But honestly, if it was all about the great syntax and sophisticated language features, we'd be still using Java applets on the web. Instead, it's all about Flash.

Honestly I'm not sure how smart it would be to invest in Google Gears. You may want to deploy a Yahoo app.. and then what? Google's also known for their ton of search-unrelated projects which they abandon the next day.

Um, are you not aware it's Open Source [google.com]! Yahoo, you, me and everyone can use it. Google could stop supporting it if they want and the community will continue to build it!

More to the point, since Google are using it themselves (see below) I doubt support will stop anytime soon. Open source

Um, are you not aware it's Open Source! Yahoo, you, me and everyone can use it. Google could stop supporting it if they want and the community will continue to build it!More to the point, since Google are using it themselves (see below) I doubt support will stop anytime soon. Open source + used & supported by a major 'net company seems like a winning formula.

You're apparently not aware of the level of battle happening right now for the rich client platform. If it would have no corporate support to push

Except that XUL isn't really made for web apps. It is really for browser interface itself and for browser extensions that are installed locally. Actually writing a networked XUL app is kind of a pain because of security restrictions. I wrote a XUL app once but found that I had to install it as an extension because I could hardly do anything useful with all the restrictions when loading from a server. And if you are going to require that users install you app as an extension, the question beco

Well, you might want an offline web application for things such as web-based word processing. When you are offline, files are cached offline. When a connection is detected, files are synched back onto the server.
I would imagine online word processing applications' weak like to be the constant need for a connection, especially if you are on a roaming internet connection.

Well, you might want an offline web application for things such as web-based word processing. When you are offline, files are cached offline. When a connection is detected, files are synched back onto the server.

How about a more basic solution like syncronized network file storage so that you don't have to rewrite every damn application inside a browser to get centralized storage? That way you can use whatever word processor or speadsheet program you want and have your data synched to the internet.

Suppose that I, for example, run a small service-oriented business, with technicians and service trucks and customer appointments, in addition to the normal gamut of meetings and other internals. Suppose that some of these technicians are located in different towns.

Suppose that, because of geographic disparity, it becomes a pain in the ass to manage a central paper-based schedule and keep everyone on the same page. And suppose I find that the solution to this problem is to implement some sort of network-aware calender. And, that I want to be able to access and modify this calender by a variety of means, from standalone PalmOS devices to Windows boxen to WinCE phones, because the different techs, salespeople, and managers all have their own levels of technical ability and devices of choice.

And now, just suppose that something like Google Calender fits this bill and is put in service. Everyone knows where everyone else is, what they're doing later today (or next week). Scheduling a job can happen easily, and conflicts can be seen and avoided immediately. Life is good, and the paper schedule is forgotten (good riddance).

With me so far?

Good.

Now, suppose that the Intar-web is down, and Google Calender is unreachable.

Trucks stop rolling. Customers get angry about missed appointments. Jobs don't get done. And, the kicker: Nobody, except perhaps the stubborn old geek with an offline Palm Pilot, has any idea what anyone (including themselves!) is supposed to be doing. The company basically takes a vacation until connectivity is restored, which (in small business) means waiting as long as it takes for Time Warner or SBC to correct the problem.

Having offline web application support, if implemented well, can fix this problem. Even if new jobs can't be scheduled electronically, at least work on existing stuff can continue, as all that it takes is one person with Firefox on a desktop machine to pass out orders.

The worst-case, then, goes from having no data at all and a complete cessation of work, to at least having old data. A notepad and cell phones can then fill in the blanks for new jobs (just like it used to), which can be entered into the calender system once the Internet connection comes back.

Firstly, while it is plain that there are already calendar synchronization applications for mobile devices, it is not plain that any of them actually fucking work across multiple platforms with a meaningful featureset. If you know differently, then please tell me about it, as from what I can see the market is full of festering shit.Secondly, it is obvious that you're not in small business. The choice between paying through the nose for a T1 with an SLA in small town Ohio, or converting to pen-and-paper fo

I suppose it might be about me, and not some general hypothetical case. Then again, it might not be.It doesn't matter.

I wouldn't hire you to mop the floors, let alone work on computers. You've demonstrated a complete lack of respect for the most rudimentary project specifications and clear-cut business decisions. You insist that the company must change to better fit the available calender products, instead of the calender products changing to fit the company.

A UI is only as hideous as the UI designer has made it. I personally make amazing and intuitive UI using javascript, html and css. You'll never see them on the web though. You may see one in a Kiosk at a museum or on the back of an airplane in first class sometime though. They run locally via a browser pulling data from a central server but pulling UI assets and logic from a client side cache.

You can do some amazing things with today's Javascript libraries, DOM scripting, CSS manipulation and a SQL store. Look at Apple's Dashboard widgets, Konfabulator widgets, etc. for examples of what can be done (and yes when you turn an amateur developer base loose with easy to use tools, they'll come up with some pretty ugly and pointless things too).

BTW Javascript is only as memory sucking as the implementation, ie the browser in most cases. A good javascript engine will not leak memory like a sieve... and a good javascript library will minimize memory leaks even in a poor implementation.

Why am I the only one here who actually thinks about usability of software?Having "web applications" that do not conform to a solid consistent format is HORRIBLE for usability. Users now have to learn how to use 10 different widget scrollbars, some which work and some that don't... instead of just using the one scrollbar their window manager comes with. There is no consistency between the GUIs of various software, and no guarantee it'll work on your particular system in the way YOU want it to work.

I use Google Docs (for non-important data) along with Gmail and Google Personal Homepage. I like the UI in all and have no problem with my computer or the page being "sluggish." Perhaps its time you updated your computer? Because mine is hardly cutting edge and has no problem. So I can only imagine how old your computer must be to be having these problems.

The EFF said don't use Google Desktop because of vulnerabilities"
"[We urge] consumers not to use this feature, because it will make their personal data more vulnerable to subpoenas from the government and possibly private litigants, while providing a convenient one-stop-shop for hackers who've obtained a user's Google password," the EFF said in a statement"
http://www.eweek.com/article2/0,1895,1925064,00.as p [eweek.com]
If Google is under pressure from some governments to hide things, from others to store and reveal things - why would people want more, more, more Google and their vulnerabilities on a computer? As bad as Microsoft is I would rather deal with the devil I still know then the Googlers who seem to want to be the center of the cyber-universe in a way that seems more grandiose than even M$. They lost me when the started censoring stuff here US never mind China.

Yeah, whatever.No company is all evil, not even Microsoft. And no company is all angelic, as most think about Google. I know you don't think Google is angelic - but I don't think they're all evil, either.

Companies look out for themselves. Once people realize that, it really helps. They aren't good. They aren't evil. They exist to serve the shareholders (or owners, if not public)...

I like the EFF, but I disagree with them on this one. The recent/. pointer to the "Ten Firefox Extensions To avoid OZMG!11" art

Google is slowly reinventing the computer... to be a lot like what it was 20 years ago, except through a web browser. Just think, in the 1970s we all used ultra-thin clients called Teletype terminals to connect to mainframes. Then came the PC revolution, and soon we all had slower machines of our own. Then all those machines got as fast as mainframes, and we got the Internet, and started connecting to each other. Now we're going back to ultra-thin-clients connecting not to mainframes but to Google's giant server farm where they store all our personal data and promise not to abuse it. Nothing ever really changes, does it?

I'm glad I'm not the only one who made that observation. I actually talked about this with my boss not too long ago (about a month or so ago, I think).The way I see it, I think that we're going to see a convergence of web-based and traditional applications... Specifically, I think that in N years (where N is some number I don't want to hazard a guess on, but not too far off...), everyone will have a personal server at home and a complement of terminals which access it. Their TV will access it, their phone,

The difference is that we all have multiple computers now. We have a computer at work, one in the living room, one in the home office, we have a cell phone running Symbian or some other advanced OS, we have a Wii or a PS3, probably some kind of set-top box with Internet access... So you have your stuff shared across many different PCs, and you get synchronization issues. What if you want to read your personal mail at work? What if you're at a friend's place and want to quickly show him some holiday pictures

Isn't it? I have a USB key plugged into my machine that has XAMPP [apachefriends.org] on it, and installed copies of Joomla [joomla.org], Mediawiki [mediawiki.org] and other PHP apps as I need. Something to synchronise MySQL databases between machines would be handy but I'm sure there's something around if the need arose.

you haven't sovled anything there chum. cross platform apps are easy with languages like ruby and python - i know i've written them. one central point of data is nothing unquie to web apps either. and the application is NOT accessable from any computer - it requires download and install privigles, negating the ONE good thing about web apps.

Of course IBM rolled this [techtarget.com] out six years ago in the Domino server, although I don't really expect Google's offering to handle Replication/Save conflicts as well as Domino does. Of course, now that there is actually another product out, the anti-Notes trolls can start complaining that the 6 year old tech from IBM isn't using the same API that the brand new offering from Google uses.

Of course IBM rolled this [techtarget.com] out six years ago in the Domino server, although I don't really expect Google's offering to handle Replication/Save conflicts as well as Domino does.

From the sound of it, Google expects the developer to handle database synchronization issues. And in some cases, you actually have to duplicate your business logic in the browser in Javascript to make the app function offline at all. Ouch!

I'm not touching this tech with a 10 foot pole. Internet access is getting more an more ubiquitous. In the not too distant future the entire concept of being "offline" will be all but forgotten. I'm much more focused on making web apps not suck when they are ONLINE. Who has time to worry about what happens when they are offline?

Thing is, I like the mozilla approach ( http://www.bluishcoder.co.nz/2007/02/offline-zimbr a-with-firefox.html [bluishcoder.co.nz] ) better. I think it's because there's no need to install 3rd party apps and such. But thing is, as it seems Google is ahead in this, and if people start adopting it (remains to be seen) then the mozilla approach probably won't stir too much water when it's released.

So it looks like this is a browser plugin. Meaning that you'd need to install it with your web application. The API is reminiscent of the WHATWG Storage Specification [whatwg.org], but appears to be a bit more sophisticated in its reach. If I'm reading this right, the biggest difference is auto-syncing of the data with a server (when you're online) rather than having to write your own synching software.

Thus this appears to be a competitor to Adobe Apollo [wikipedia.org], but without Google defining their own container format.

Interesting. I'm not quite sure what to make of it as it's not anything that hasn't been contemplated before. Personally, I'm hesitent to adopt anything that can't be used on a live webpage as well as downloadable "webapps". However, that may not stop others who have good ideas on how this might be used.

It seems that Google Gears can be used for more than offline applications. It includes tools for running JavaScript in background threads to prevent UI blocking, as well as a SQLLite database for storage and fast retrieval of any data you want, whether you're working offline or not.

It seems that Google Gears can be used for more than offline applications.

Yes, but you have to get the user to install the plugin and accept the security warnings. Only *then* will it be available to online apps.

The market has been avoiding plugins for a long time due to the difficulty of getting end users to install the plugin software. Even with the (relative) simplicity of Microsoft ActiveX install, it often turns off the users. As a result, there are only two plugins you can (mostly) count on: Flash and Java. And that's only because they're usually installed by default.

Anyone using this for online content is taking a pretty large risk unless they control the computers that run it. e.g. It might make sense in corporate settings were updates are pushed by a central server. But that's a much smaller portion of the market than, say, Google Docs.

Of course, I imagine that Google will try to make some of these issues go away by shipping the software as part of their Google Desktop and GTalk downloads. Combined with potential downloads for the desktop application versions of their webapps, Google may get a pretty good market penetration. In which case their solution will be awesome. (Yay!) Though still only a psuedo-standard. (Boo!):-)

* IE7 has reversed that trend with plugin pages being blocked by default. Try their demos in IE7, and you'll find it to be less userfriendly than it should be.

What you call a "pseudo standard" is how good standards are created: first you use and document a technology, then, after several years of practical use, you go to a standards body.

Unfortunately, these days, a "standard" seems to mean to many people a rubber stamping of some idea that some committee or engineers cooked up, with little or no practical usage. W3C is guilty of that, and ECMA even more so.

Unfortunately, these days, a "standard" seems to mean to many people a rubber stamping of some idea that some committee or engineers cooked up, with little or no practical usage. W3C is guilty of that, and ECMA even more so.

Your ideas intrigue me and I'd like to subscribe to your newsletter.
Seriously, though, that is the truth: many standards have become these cut-out-of-the-mold pipe dreams that, while they have definite possible strengths, lack solid testing and real-world integration. It seems the rush these days is to get X idea standardized, instead of getting X idea actually used and useful. A byproduct of the patent rush/I'll-sue-you-for-knitting-the-same-color-sock s-as-me age?

It appears obvious to me, though I've been wrong plenty of times before, that this is another part of the puzzle for Google Docs. Once they've 'perfected' the system you won't have to worry about your link being up to be able to get to your docs. The next step is an intranet version for the enterprise. All in good time...

<QUOTE>Am I the only one who thinks the Big 4 browsers should be supported, and not just FireFox/IE?</QUOTE>Am I the only one that thinks websites should be coded to the standard and browsers that don't imeplement them can be left without?

Actually, it's easier now than ever before. All of the big libraries for javascript like Prototype and (my favorite) jQuery already deal with the cross-browser stuff for the most part. If you use them, you'll rarely run into a place where the difference between browsers is a problem if you know your stuff beforehand. It's still pretty rare even if you're just learning, but knowing you way around makes it even easier.

"The initial code is aimed at JavaScript developers who write Ajax-style Web applications. It runs on Internet Explorer on Windows; Firefox on Windows, Mac OS and Linux; and on the Safari Mac OS browser."

I'm inclined to believe that CNet made the mistake. Google claims that it works on Firefox for OS X. My guess is that CNet either assumed that OS X support == Safari support or they decided to preemptively report the upcoming Safari support.

i simply do not understand this statement? is it about reaching the most users or about you having a bug up your ass?

It's about coding to the standards. Firefox, Safari, and Opera are all (more or less) standards compliant. It's quite easy to write code for all three of them. IE is NOT standards compliant, and has become a cancer upon the web. If enough sites start pushing neat features that IE doesn't support, users will begin upgrading to a better browser. (One that looks better, too!) That will either force Microsoft to fix their browser or make IE irrelevant.

Of course, that's just a pipe dream for now. But with neat stuff like Canvas, Storage, Event-Source, Video, and Audio showing up in the latest web browsers, it's tempting to pull the plug on IE for even a small portion of a site. Especailly sites that provide services to popular embedded devices like cellphones or the Wii.

Actually, google tends to pull the plug on Safari support, not IE. Mainly because google likes using things like XSLT and Design Mode.. which work in IE/FF/Opera but not in Safari. That's why Google docs and picassa support everything but safari.

I'd rather put a sign up on my site that says, "IE Users not welcome, upgrade to a REAL browser" than not support the millions of mobile and home gaming machines out there.

i simply do not understand this statement? is it about reaching the most users or about you having a bug up your ass? the "millions" of mobile and home gaming machine users out there you talk about don't even make up 5% of most web traffic and ie is, what, in the 80-90% range?

The main difference is that users of alternative internet devices generally don't get to choose their browser, whereas most IE6 users are a few clicks away from running Firefox, Opera, or at least IE7.

I agree with the GP; it's better to assist the disabled than the lazy.

Of course, if you're running a commercial site and hits = money, priorities change. But I'd still rather offer IE6 users a reduced-functionality version of the site (with clear instructions on how to update/replace their browser) than waste tons of time and effort on a "No Browser Left Behind" policy.

Dojo uses whatever storage service is available. That includes WHATWG Storage, Flash storage, and IE controls.

The biggest difference with Google Gears is that the storage mechanism can be configured to automatically sync with the parent server. It also allows you to run your code asynchronously as well as provides direct access to an SQLLite database. However, these features are secondary to the primary purpose of providing auto-synced data storage.

I work on several computers. I have a couple at home, one at the office and a laptop that I use when I travel. This sort of thing means I don't have to load the same software on each machine if I want to work on something online and offline.A specific example is my family history.

I use phpGedView and keep it online so my family members can see and contribute. I also like to work on it during downtime, like in airports and while traveling. I don't always have a net connection. The application is online

Getting my school to download a PonieDocs app just for me and a SoKewlDocs app just for Bob and a FakeDocs app just for Jim might not be easy. Convincing them to install one plugin for 3 people though, is 3 times more likely to get them to do it then 3 different apps for only 1 person each.

Why not just create a desktop app that talks to the webapp through web services when you get back the connection?

Because the common case is that people are online, and it makes sense to build the best app for that, and that's often a web app these days. Even if you wanted to spend the money to develop two apps, that still would be a bad solution for users because they'd now have to learn two user interfaces.

because last time, Microsoft was Google, and IBM was Microsoft. But now Google is Microsoft and Microsoft is IBM. If you haven't read any of Clayton Christensen's books, now would be a good time to read The Innovator's Solution [theinnovat...lution.com] by Christensen and Raynor. Ever since the telephone, small upstart companies have been offering products and services that were shunned by the market leader's best customers, and hence the market leader, usually because the product underperformed the expectations of the market leader's best customers. But the market entrant was able to make enough profit and gradually got better and better, and then started pulling customers out of the market leader's business network.

RCA didn't use transistors in small radios until it was too late. Western Union didn't use the telephone until it was too late. Microsoft didn't work with the FOSS community, and now it is too late. Google is great at broadcasting software. Microsoft is still mostly delivering software the old, slow way. This news is another digital tipping point. The OS is becoming less crucial. GNU Linux is getting its foot in the door with Dell. Google and 1000 other new start ups are using the power of FOSS to do creative stuff. Microsoft seems to be focused on older business models (DRM'd content) while Google continues to broadcast everything from its own software (Google algorithms on Linux) to fun, new format for video (YouTube shorts). I think that we are going to see some major changes in the way that desktop software is funded, distributed, and delivered. Once the Microsoft monopoly on the desktop is cracked, think of the changes we will see.

This is sad. As a programming language, Javascript makes Visual Basic look good.

How is that? Javascript is a pretty good duck typed prototype-based language. The syntax is similar to c++, but being interpreted you have awesome RPC features built in eg. JSON [json.org]. I don't get how you could even compare the two.