Category Archives: software development

Google’s new model of app development

I was fascinated by this slide shown at the recent global developer day, which I’m reproducing with Google’s permission:

Four blocks captions Ads, Standards, Mashups, Open Source

The image doesn’t make sense without the caption, which I’ve used as the title of this post: The New Model of App Development. You can see the slide in context in this Register piece. Two things in particular interest me. One is the appearance of ads as an integral part of the development model. This makes sense for Google’s own development, but does it make sense for others? Given that much of the software industry is slogging away at internal business applications, that seems a stretch. It may be true for consumer apps. Ad-funded applications have not been a big success on the desktop, but we have somehow become tolerant of ads flashing round the screen when working on the Web.

Another issue is one we tried to capture in the caption for this image at the Reg. The main goal of developer day was to get developers to integrate Google services into their applications, by using Google Maps and the other APIs on show at Google code. The company is even keen to host your gadgets on its own servers. Google wants to be an indispensable building block in app development, even though it left itself out of the illustration.

How about open source? Google uses and sponsors open source software, and has posted the code for Gears, but where’s the code for Docs & Spreadsheets? Closed source is an important part of Google’s own app development model, as it is for most others.

Adobe Live in London – quick report

I attended Adobe Live yesterday. This was in two parts, an exhibition with a schedule of presentations/tutorials, and a developer day focused on Rich Internet Applications – Apollo and Flex – as well as ColdFusion 8.

I’m told that around 1800 attended, though most of these were for the main exhibition, whereas I spent almost the whole day in the developer sessions.

It was a worthwhile though low-key event and I picked up some insights into Apollo and Flex 3 as well as getting an update on ColdFusion. I’ll be reporting in more detail shortly. A couple of quick comments though.

First, this struck me as primarily a designer crowd, Flash folk interested in applications, rather than developers new to Adobe. These are just impressions so I could be wrong, but it strikes me as in interesting issue. Equally, when I went along to Microsoft’s Mix07 earlier this year my perception was that many delegates were primarily Visual Studio folk interested in web design, rather than vice versa. If I’m right, Adobe and Microsoft have inverse cultural and marketing problems here. Still, at least Adobe put on a proper developer schedule this year; it didn’t exist at last year’s London event.

Second, I found the Apollo stuff though-provoking in the light of Google’s Gears announcement as well as what Microsoft is offering with WPF. I knew that Apollo was sandboxed, but hadn’t appreciated the extent of the sandboxing. As I understand it, Apollo apps can do file i/o on the local machine, but in other respects it is locked down in a similar way to web apps running in the browser. There is no access to external libraries, OS scripting, or custom native code extensions.

That’s good from a security perspective, but it limits the extent of OS integration. So the key question: if you can’t integrate with the OS, beyond a few trivia like Start menu or Dock shortcuts, then why bother with a desktop app? Especially now that Gears has a solution to the offline problem. Maybe it is worth it just to get out of the browser window, but some at least will not see the point.

Third, I asked what if anything Adobe intends to do with Google’s open-source Gears code, but apparently I may not have the full story yet – more when I get the information.

Technorati tags: , , , , ,

FireFox team not sure about Google Gears adoption

During Google Developer Day I had the impression that Mozilla was right on board with Google Gears, the plug-in which which enables offline applications. Here’s Aaron Boodman and Erik Arvidsson from the Gears team:

We are releasing Gears as an open source project and we are working with Adobe, Mozilla and Opera and other industry partners to make sure that Gears is the right solution for everyone.

It seems that things are not as clear-cut as Boodman and Arvidsson imply. LinuxWorld.com quotes Mozilla’s Mike Shaver:

We’re talking to Google engineers and looking at how these two models — ours and theirs — compare. This is in the open now, and going forward we’ll see what we can learn from each other,” Shaver said. “But there’s a lot of work that’s been done already [on Firefox 3.0], and we’re not planning to throw that work away.

According to the article, Shaver is particularly doubtful about using SQLite for persisting web application data locally, and is inclined to stick with the more limited DOM Storage API already planned for FireFox 3.0.

A related point is that Adobe’s commitment to Gears is not absolute. Here’s Adobe’s Michele Turner says, quoted by David Berlind:

…For example, they’re using SQLite and we were already incorporating SQLite into Apollo. So, now we’re aligning our efforts with Google on things like the synchronous and asynchronous calls that must be made to the SQLite database in order to enable the offline capability. 

My impression is that Adobe is aiming for a measure of API compatibility, but will ship its own build of SQLite rather than using one installed by Gears, with inevitable version and customization differences.

There is a world of difference between using a similar API on the one hand, and sharing common components and/or common source code on the other. It looks to me as if Apollo, FireFox and Google are going to provide three independent and isolated mechanisms for handling local storage.

Of course Gears installs into FireFox anyway, and there is nothing to stop Flash developers from using Gears.

I will quiz Adobe on this subject at tomorrow’s Adobe Live event.

Google: Don’t let your kids use Gears

More Google Gears Terms and Conditions madness. Gears is licensed under New BSD terms; yet before you can install the runtime you have to agree to onerous terms and conditions. Here’s clause 2:

2. Accepting the Terms

2.1 In order to use Google Gears, you must first agree to the Terms. You may not use Google Gears if you do not accept the Terms.

2.2 You can accept the Terms by:

(A) clicking to accept or agree to the Terms, where this option is made available to you by Google in the user interface for any Services; or

(B) by actually using Google Gears. In this case, you understand and agree that Google will treat your use of Google Gears as acceptance of the Terms from that point onwards.

2.3 You may not use Google Gears and may not accept the Terms if (a) you are not of legal age to form a binding contract with Google, or (b) you are a person barred from receiving the Services under the laws of the United States or other countries including the country in which you are resident or from which you use the Services.

I’m puzzled. If Gears is BSD licensed, how can Google insist that the mere act of using it binds me to these terms (which I dislike for other reasons too)? And 2.3 is bewildering: you may not use Google Gears apps if you are not an adult?

What if someone else installs Gears on your machine, and you then use a Gears-enabled app? How can terms like this possibly apply in such cases? Note that the agreement does not refer only to installing Gears, but specifically to using Gears.

By the way, you can download the source for Gears, and compile it if you can figure out how, without assenting to any such agreement.

I think Google is letting its legal team get out of hand.

Technorati tags: , ,

Why Google Gears? Thoughts from Google Developer Day

Google Gears is a browser plug-in to support running web applications offline. It has several components:

A local server – not a complete web server, but a cache for web pages. One of its benefits is to solve versioning issues. For example, what if you had an application that retreived one page from the cache, complete with Javascript, and another from the Web, including some updated Javascript? The app would likely break. The Gears local server lets you define a set of pages as an application, so you can ensure that either all or none of the pages are delivered from the cache.

A local database. SQLite of course. I can think of many uses for this – whether or not your application needs to work offline. Searching and displaying data from a local database will be quicker than retrieving it remotely. In the current beta, there is no limit to the size of the database you can download or create on the user’s machine.

A WorkerPool for running Javascript in a background thread. Again, there are many possible applications, but a key reason for its inclusion is so you can do long-running synchronization tasks in the background.

A Javscript library to enable access to all these goodies.

Synchronization

Synchronization is integral to the Gears concept. The idea is that your web application works the same online and offline; and then when you reconnect, any changes you made offline are transparently synched back to the server. Google’s demo app for Gears is Reader, a blog reader app, but you can see how this would work nicely with Documents and Spreadsheets, removing one of the disincentives for its use. I’m reminded of comments from James Governor and others about the Synchronized Web – cloud storage, but with full offline capability.

Gears vs Apollo

How does Gears impact Adobe, which is promoting offline web applications in the guise of Apollo, desktop applications running on Flash? You can argue this either way. On the one hand, you could say that Gears removes the need for Apollo. Now any web application can work offline. On the other hand, you could say that Gears is not targetting the same space. Apollo is for desktop apps; Gears is for web applications that happen to work offline.

My take is that Google is making its pitch for ubiquitous web apps which break the offline barrier. The attraction of Gears is that it is seamless, at least for the user. Look at the reader example: it’s the same app, but now it works offline. As I see it, Google is saying that you don’t need Apollo (or WPF, or Java) for compelling apps that work connected and disconnected. That said, it’s not against Flash; there are even handy Google Javascript APIs for simplifying SWF hosting.

Another twist is that Adobe says it is supporting the Gears API in Apollo. That presumably means Apollo now has a fast embedded SQL database engine, which must be a good thing.

 

SQLite will be everywhere

One of the core components in Google’s new Gears API is SQLite, an open source database engine. I’ve been an enthusiast for SQLite for a while now – I first blogged about it in 2003. I’ve also worked a little on SQLIte wrappers for Java and Delphi.

It’s a superb embedded database engine and I’m pleased but not surprised to see it now picked up by Google. It’s part of PHP 5.x, and also used by Apple for Core Data and Spotlight search in OS X. Now it is part of Gears and I imagine will be widely deployed. Google is also apparently contributing to the project – Full Text Search has been mentioned here at Developer Day – though I’ve not yet looked at this in detail. Congratulations to the primary author D. Richard Hipp, truly a star of the open source world, and thanks to him for making SQLite “completely free and unencumbered by copyright“.

 

Google’s offline problem

Here at Developer Day I attended the workshop on new Maps API features. Unfortunately I was one of the last into the session and could not connect to the internet. I suspect a problem with IP number allocation but I don’t know for sure. I spend some time trying to get it working, then gave up and returned to the blogger lounge, where the wi-fi worked perfectly.

A let-down; yet nicely illustrates the reason why we need Gears.

That said that, even Gears isn’t going to enable offline Geocode lookup.

Next up is the session on Gears.

 

Technorati tags: , ,

My question to Google

I grabbed the first question after the opening keynote today. It was prompted by my visit to the Google Gears site – I’d intended to install the beta. I was confronted with this dialog:

I asked:

Why does Google display an 8-page agreement in a box 7 lines high?

More significantly, why does it include this clause which strikes me as unreasonable:

12. Software updates
12.1 The Software which you use may automatically download and install updates from time to time from Google. These updates are designed to improve, enhance and further develop the Services and may take the form of bug fixes, enhanced functions, new software modules and completely new versions. You agree to receive such updates (and permit Google to deliver these to you) as part of your use of the Services.

Of course I’ll have to install Gears; I can’t do my job otherwise. But I’m inclined to do so in a virtual machine, because I prefer to keep control of what gets installed.

There’s plenty more in the agreement that you might object to- have a read and see.

It all sits uncomfortably with the stuff we’ve heard about how much Google loves open source, Creative Commons licenses and so on.

My question wasn’t answered, but Chris DiBona invited me to email him with the question, which I’ve done, referencing this post.

Technorati tags: , ,

Google Developer Day begins

I’m early to the London event; but registration is open and I get a flimsy red bag with oddments including a tin of “Goo” which turns out to be thinking putty. The event is at The Brewery in the heart of the City. We are ushered into the Blogger Lounge – stylish, with bright-coloured cushions, soft pastel lighting, fresh-squeezed orange juice and no chairs. A quick glance around the room tells me that Macs outnumber Windows by about 4 to 1.

The event will kick off with a keynote from Chris DiBona “Developer message” and Ed Parsons “Geo Message”. Then I’ve got API workshops – lots of AJAX and Maps – and closing with another keynote live from Mountain View.

I’m already familiar in a broad sense with Google’s developer offerings, but what is the strategy? Getting closer to that is one reason to be here. The other to assess how useful all this stuff is in the real world – to developers that is, rather than to Google.

Delegate using laptop station at Google dev day in London

More as it happens.

Technorati tags: ,

Not convinced by LINA

Set for public release next month, LINA is a new approach to cross-platform development. Write your app once, for Linux, then deploy using a lightweight virtual machine, implemented for Windows, Mac and Linux. Why even Linux on Linux? Well, on Linux compatibility is a problem, with a multitude of different distributions out there. A VM provides a secure, reliable and predictable environment for your app. LINA’s creators claim to have solved the obvious problems: access to resources in the host operating system, and matching the look and feel which the user is expecting.

I’ll look it with interest when it appears next month, but I’m sceptical. It strikes me as a heavyweight approach, and I’d like to see the extent to which LINA blends with the host O/S before believing all the claims. Some of the publicity annoys me too. Here’s a quote from the white paper:

All computer users – individuals and organizations alike – make the most fundamental software decision when they choose an operating system. Historically, this choice locks the user into a single, clearly-demarcated realm of available software. As a result, Windows and Mac users have virtually no  access to the vast world of Open Source software.

I do most of my work on Windows Vista, so apparently I have “virtually no access” to open source software. Yet happily installed on the Vista box in front of me is:

  • Open Office
  • FireFox
  • Filezilla
  • Apache web server (installed with Delphi for PHP)
  • Tortoise SVN (Subversion client)
  • 7-Zip file archiver
  • Audacity sound editor
  • Ethereal Network Protocol Analyzer
  • NetBeans Java IDE
  • Eclipse Java IDE

and I’m sure there is more if I spend time looking. All open source, mostly cross-platform. Some of this is on the techie side; but the first two above are true mainstream apps.

Writing cross-platform apps is still a challenge, but easier than was the case a few years back, with numerous viable approaches available. So do we really need LINA?