As others have said, the goal ultimately with this kind of work is (or should be) standardization. Web tech-based apps really should be able to run anywhere you have a decent browser.
(I work for Mozilla, but not on our Apps work specifically)
Yeah, there's been discussions between the teams working on this at Google and Mozilla. I think the lack of coordination on a standard at this point is mostly because everything is still very much evolving. No one's sure exactly what's right, and we all learned the dangers of premature/aspirational standards from the start of the last decade (e.g. SVG). This is the time to iterate and figure out what works. The standards time will come once there's some real-world experience in what they should be.
There are various reasons why no one has chosen to implement that standard. My personal discomfort is that it basically punts on the security portion and leaves most of the scary stuff entirely at the discretion of the implementor. For that reason alone I personally think the spec is a non-starter.
This is not new, my packaged app has been in market for a long time now. The APIs are always developing. Such apps have been possible for some time now.
edit: to be precise, my app is almost a year old and the packaged app stuff was there even before that. And in chrome world, twelve months is a very long time.
It will launch in a window in chrome OS in the new interface. It is a packaged app as in all of it's resources are bundled in the crx and it does not need anything from the web.
The difference b/w this and old version is that it has access to more apis. The underlying idea of a packaged app (that all data is bundled in .crx file) is same for both of them. This is discussed here. http://code.google.com/chrome/extensions/trunk/apps/app_arch...
This feels quite a bit like Fluid or Prism, as others noted. Interestingly, though, it looks quite a bit like writing a plugin for Chrome rather than a webpage (http://developer.chrome.com/trunk/apps/about_apps.html) and the new APIs are going to be interesting.
Integrating it into the OS might lead to unpredictable factors like Microsoft or Apple removing that kind of functionality from their future OS versions.
HTML5 apps were Steves original vision. Add to homescreen exist because that was supposed to be the way to deliver new apps to users on smart phones.
Why should Apple destroy that? To protect their 30% cut from a store that doesn't bring in a profit? For heavens sake why?
Apple makes money when you buy an Apple product. They want to make it so that you want to buy more Apple products, not fewer. If removing the capability to add HTML5 apps to the home screen causes a loss of just one Apple product sale, it is not going to happen.
1. User sees a listing of XLS or DOC files in the web app, stored in the web app's local storage, user clicks to open a file in a default native office application such as MS Office, and registers a "watchFile" callback to be notified of any changes to the underlying file data (when the user presses CTRL+S in the native office application), to enable syncing to the web app's local storage.
2. Web app is granted read/write access to a directory on the user's system, so that if a user opens a file in this directory from outside the web app, the web app can still watch changes made to these files to enable syncing to a backup server etc.
3. Packaged apps as complete binary installs, without requiring Chrome to be installed on the user's machine, and without requiring the user to visit a proprietary web store or sign up as a Google user. The user should not know that they are installing a packaged app. This binary would need to be able to be marketed and installed from outside of proprietary web stores if packaged apps are to be a success. i.e. a website could offer a .dmg or .exe download link depending on the platform. The app would include the Chrome updater and auto-update to track the latest packaged app apis.
It would also be a huge help if the POSIX, TCP, UDP APIs could match that of Node.js and have similar performance characteristics and capabilities (fsync etc).
Standards bodies are meant to formalize technology that already exists. Good luck getting a standards committee to innovate and come up with new features.
(BTW, IE gave us XmlHttpRequest. It was not introduced by a standards body. )
If it's open then that argument is irrelevant. MS's Embrace Extend Extinguish is only applicable for proprietary standards. Open standards are the cure for that.
If any other browser can use the exact same technology Google uses, then that's fine. That's how other technologies get adopted by browsers, too. As soon as most of them adopt one, then it usually becomes a standard.
Also, I'll give you a much worse example, that has already happened, rather than something that may happen in the future, like what you're suggesting - h.264. It "completely bypassed" the standards body as well. The standards body would've much rather used something open source and free, but since most browsers used h.264 for the video tag, and since 2 of the major browser makers, Microsoft and Apple, were unwilling to go with an open source codec, the standards body was forced to adopt h.264.
Standard bodies exist to standardlize already existing technologies so others can implement them.
And btw did you miss the experiment part of all the non-standard APIs? About the only thing that wasn't was the manifest (which is JSON) and the icons.
Am I right in guessing these types of apps can only be supplied to users through the Chrome store?
If so, then: No. thank. you.
I will just never, ever, ever, EVER build software that needs to go through some sort of "approval process", unless I'm being paid a lot of money to do so. The fact that some dweeb at google has ultimate power to simply reject all my hard work, or even worse, approve it first and then remove it at a later time, barring all my users from accessing the app, all without me having ANYTHING to say about it is just fascist and wrong. I would never work under such a system (App Store, Windows Store, Chrome Store, etc...)
I need to be free to provide my application by any method I want, that includes a download link anywhere on the internet that lets users install the app when they want, if they want, however they want, without fear of some overlord stepping in and banning the app.
"Don't mind me, just makin' a straw man, knocking it down..."
Chromium is entirely open source. A quick search shows that there are many bugs/mailing list posts mentioning packaged apps within the Chromium project. So the answer to your hypothetical question is: no, you're likely not right. Google may control the experience in the Chrome browser, but by providing all the code they use, you're free to implement whatever system you want on your own machine.
Parent said Chrome store, not Chrome. If apps can only be installed from the Google Play, nothing guarantees us that your homebrewed system can access them.
Well where do the apps come from? Developers. If the developers are willing to post versions of their apps that will work on Chromium in addition to Chrome Store versions, then you'll be able to use them. If they aren't then your issue is with the developer, not Google.
It still works on Windows, just rename a .html file .hta. You get the appearance of a real application and special privileges through windows scripting.
On an unrelated note
I like that application development is moving in the direction of using web technologies for offline software, but I don't like the fragmentation I'm seeing with the Windows Metro apps, Chrome apps, Firefox OS apps, Phonegap apps all using different manifests/APIs.
It would make more sense for developers and consumers if some of the people working on these were to work together and come up with a standard.
I don't use iOS, but Chrome has had "Create Application Shortcut" since I think version 1. The Chrome apps platform is very different from that, and probably more comparable to iOS or Android apps, or what Mozilla pursued with XULRunner.
> I don't use iOS, but Chrome has had "Create Application Shortcut" since I think version 1.
Does "Create Application Shortcut" stuff work offline for compatible web applications, or does it just create a shortcut to a chromeless version (à la Fluid)? I can find no conclusive evidence towards the former by browsing.
the short answer is yes. The slighter longer answer is that the application shortcut is just some extra command-line parameters, and doesn't materially alter the workings of offline stuff like AppCache or LocalStorage.
Does anyone know how updating software versions work in this system? It would be nice if offline applications would work the same way as the HTML5 app cache.
The autoupdate system compares versions to determine whether an installed extension needs to be updated. If the published extension
has a newer version string than the installed extension, then the
extension is automatically updated.
There's some superficial similarities, but they're very different in practice. The most obvious thing to me is the security model (which is non-existent for HTAs). In fact, HTAs are broadly considered a dangerous file type at this point, because they implicitly have full privilege of the user that runs them. By contrast, Chrome applications prompt for any required permissions (defined within an explicit security model) and are confined to their application container. A Chrome app can interact with the OS and external systems only through those allowed permissions and authorized intents.
HTAs also lack many of the aspects of real applications. Many common operations just aren't possible with an HTA (e.g. basic network sockets, USB devices). And HTAs don't support any significant OS integration, such as file associations. In contrast, Chrome apps are intended to be robust enough to support something as ambitious as implementing your own browser, but to do so using a safe, portable framework.
You are correct, of course, but it seems to me that the only reason for thus situation with HTA is that it never took off and MS dumped its further development. Which makes me wonder if these kinds of technologies simply have no future whatsoever, or are yet to be accepted by the mainstream.
With access to the FileSystemObject or automation access to an OCX you could do either of those things. The power of HTAs is you could use anything provided by a Microsoft technology, script Office, access WMI, etc.
I wrote a DVD backup solution using HTAs and FSO.
Fun fact: Opera has had "widgets", which are basically the same thing as this, since version 9 (2006). They could run without having the main browser open, and when I looked inside their folders, I was surprised to see that, indeed, each one had an actual ".exe" file. I doubt you'd be able to distribute them though. They are deprecated now for some reason.
This is all a terrible idea and it will fragment the Internet as we know it. The internet is not a budget strip-mall of different low grade outlets; it's more an orchard full of fruit you can discover and pick at will from millions of trees.
What people have invented is HTML applications, much as Microsoft promoted in the early 00's with some marketing and store ceremony around them.
Also, let's look at NaCl while we're here: it's basically a modern version of ActiveX.
Then we had silverlight, which was glorified Flash for LOB applications and could be out-of-browser. I wonder how long it'll be before Google invent that again.
All those are dead, and for a good reason.
Microsoft even sees that these approaches are just bad and has pushed away from them heavily recently apart from in the desktop and mobile space where they are 100% REQUIRED.
As far as their integration goes now, you can pin sites to the taskbar and there is no massive ceremony or framework around it - it's just a glorified bookmark.
Just because Google packages it up and throws it into the fad browser of the day, don't assume it's not the same golden turd that we've all hated in the past.
George Santayana: "Those who cannot remember the past are condemned to repeat it."
You're very confused about these technologies. NaCl and ActiveX aren't even remotely comparable. ActiveX is a method for deploying arbitrary binaries via the Web, and history showed it to be extremely dangerous. NaCl is a method of running thoroughly sandboxed native code; because NaCl is machine specific, it's deployed only through Chrome extensions/apps, and there's no intention to expose it directly to the Web. PNaCl adds a portable bytecode layer on top of NaCl, and is intended as a general Web technology. Realistically, it's more comparable to Java or .NET, only lower-level, more performant, better security, and no one's going to get sued for using it.
Both have sandboxes (ActiveX since Windows 6.0, IE7), both have restricted APIs, both run native code.
PNaCl is equivalent of silverlight which is cut down CLR.
More performance - I doubt it. CLR+JVM is pretty much up there. The moment you add any virtualization, trap code or translation layer to native code via NaCl which you will require for security, there is going to be overhead which will knock it inline with a VM architecture. Startup time might be less - that is it.
Better security - that's a lie. Virtualization on any layer never gave anyone better security. It's throwing stones in glass houses. The only hard security boundary is at the MMU/page table. As NaCl grows, you will see it break.
No-one getting sued? I'm sure the EU will have something to say when no other vendor implements it and Google uses it to leverage market share, much like Microsoft did in the late 90's and early 00's.
I'm sorry, but you are so grossly wrong in your statements that the only valid response is a bit of a fisking. Normally I'd prefer not to respond this way, but I've already engaged you, and I can't really let this much misinformation stand.
> Both have sandboxes (ActiveX since Windows 6.0, IE7), both have restricted APIs, both run native code.
ActiveX is a general purpose object API and has no sandbox at all. IE 7+ on Vista+ can instantiate ActiveX controls in a weak sandbox via low-integrity mode, but to imply it's comparable to the NaCl sandbox is just comically ignorant. NaCl validates the nexe's conformance and its subset of x86 instructions before it will run it (in that way being very similar to Java and .NET CLR). And NaCl runs entirely in an outer, system-level sandbox that denies all system and object access.
In contrast, IE's low integrity mode lets you read anything the user can, exposes massive chunks of the system as attack surface, and provides various writeable locations. On top of that, all non-trivial ActiveX controls in IE implement brokers which run fully outside the sandbox--something that's not even possible with NaCl.
> PNaCl is equivalent of silverlight which is cut down CLR.
Nope. And making that claim begins to underscore just how little you know about this.
> More performance - I doubt it. CLR+JVM is pretty much up there. The moment you add any virtualization, trap code or translation layer to native code via NaCl which you will require for security, there is going to be overhead which will knock it inline with a VM architecture. Startup time might be less - that is it.
Virtualization or trap layer? That's not even close to how NaCl works. It's really sad that you couldn't be bothered to read a one-page explanation of before you launched into this completely wrong-headed diatribe. Please, start here next time, so your trolling can at least be superficially informed: https://developers.google.com/native-client/overview
> Better security - that's a lie. Virtualization on any layer never gave anyone better security. It's throwing stones in glass houses. The only hard security boundary is at the MMU/page table. As NaCl grows, you will see it break.
Once again, premised on your total ignorance of the subject matter. Come back when you have at least a basic knowledge of the thing you're criticizing.
> No-one getting sued? I'm sure the EU will have something to say when no other vendor implements it and Google uses it to leverage market share, much like Microsoft did in the late 90's and early 00's.
I'm sure there was an attempt at making an argument in this last line, but mostly it just seems to be randomly scrambling for scary sounding words.
I'm sorry if you feel slighted, but I'm only attempting to dispel your ongoing stream of misinformation. And even after being corrected, you've persisted to the point where it's hard to perceive your behavior as anything short of intentional malfeasance.
As for the strawman in your latest comment, no one made any claims of "a flawless sandbox." I rightly pointed out that the security model of NaCl is far more robust, and you've offered nothing to counter that. Now, of course, software is going to have bugs, and the ones listed in that paper are significant. Fortunately, no combination of those bugs could have breached the outer sandbox, and would not have represented a real-world system compromise.
The origin of that paper also circles back to a very important point. We realize that we need to attack security from many different angles (fuzzing, sandboxing, bounty programs, etc.). And that paper you cited was actually the result of Google sponsored competition in 2009 against a pre-release version of NaCl. The authors were the second place winners, and have continued to research NaCl's security both as independent researchers and paid consultants. (One of them is actually presenting at Black Hat on NaCl security this week.)
My point here is that an objective read of the paper really paints NaCl very positively from a security perspective. Had you actually looked at the content rather than just made an assumption based on the title you would have been aware of that.
The real problem with ActiveX wasn't the technology, it was the API. Code relied on a large, complicated, ever-changing API which was practically impossible for others to duplicate. Win32 was for the most part documented, but even a decade later Windows XP programs are often not useable in WINE.
This is the same problem with NaCL. The API is complicated and has a bunch of browser-specific features. Firefox can't just include "pepper.c" and have NaCL support, there's tons of work involved. One result is that Firefox won't support Flash for Linux anymore. Implementing Pepper, even though it's "open source" is more of a hindrance than not having Flash.
NaCL is better technology than ActiveX, but uses the same idea of leveraging a OS/browser-specific API as a handicap for competitors.
The earliest versions of NaCl attempted to align to the mess that is NPAPI, but that was literally years ago. For the last few years NaCl has used PPAPI, which is well-defined, more loosely coupled to the web, and has a clean versioning mechanism: https://developers.google.com/native-client/pepperc/
I see hundreds of APIs and beta APIs. There's no source code repository. The python scripts to download a SDK refer to Google "private_svn".
So Google spends 6 months working on the next version and Firefox and Opera don't even get access to it until the next SDK and are 6 months behind, and they have zero input in how it evolves. That's not how open source should work.
The other is a link to a build of pnacl sdk that also doesn't include source (src/ folder is empty).
Am I being dense here? Where's the hg, github, code.google link that actually has the source code? I couldn't find where the source is. You would think that would be pretty obvious for an open-source project, like maybe some giant button on the project page.
Anyway it doesn't change the point. This isn't being developed as a public open-source project. It isn't designed to be easily added to browsers other than Chrome. Like ActiveX, it's being used as leverage to make one browser better at the expense of others.
I can appreciate that you're unfamiliar with the build and dependency management tools used by Chromium and related projects. However, it's disingenuous to imply that somehow the project is any less public or open because of that.
Some dependencies are pulled in and set-up by the checkout scripts, which is not an unusual degree of complexity for a large group of projects with such broad dependencies. It's all clearly documented and everything you need to know to checkout, build, and contribute code is linked from right here: http://www.chromium.org/nativeclient
I think you pretty much proved my point. NaCL is a sandbox, the very thing that should have the cleanest, clearest delineated lines. But there's no standalone version, no stub version. And you seemingly need a PhD in Chromium to even find the source much less get it working in anything else.
I guess Mozilla is unusually capable then because their download link is right here:
So you're working on Chromium and think navigating a buildbot to get python scripts that download from a private svn is not unusual... ok fine, but don't be surprised if people don't want to touch it (or even can figure out how to). I certainly understand better now why Mozilla would rather just drop Flash support.
Looking at the code, you have to check out the source and then run another script to check out the source from Google's private source control system/depot.
Why it isn't just in a public repo, I don't know. It looks like it is set up so they can pull it at a moment's notice.
This is just silly. You can't say that you can pull the code from a public repository, and then claim it's private. If it's set up so you can pull the code, and you do so successfully, then it's by definition public. It's totally understandable that you're unfamiliar with how the the projects and dependencies are distributed. The Chromium projects are one of the largest and most complex codebases you're likely to encounter. However, it's all clearly documented and public, with numerous open source contributors. So, it's very disturbing that your first thought is not try and learn why, but rather to insinuate some irrational conspiracy theory.
Everything is in public svn and/or git repositories. The thing that's confusing you is probably how modules are split out as dependencies. They're not checked directly into the tree, and instead are listed by repository URL and pinned revision in DEPS files. On checkout and sync gclient pulls the correct revision from the appropriate repository: http://dev.chromium.org/developers/how-tos/depottools#TOC-DE...
I don't understand your argument here. NaCl is an open source and openly developed project that anyone is welcome to participate in. The repository, tracker, and mailing lists are all public. In fact, the NaCl team has made numerous efforts to involve the other browser makers (even if they haven't shown interest so far).
> "The internet is not a budget strip-mall of different low grade outlets; it's more an orchard full of fruit you can discover and pick at will from millions of trees."
Maybe it's just me, but I'm having a difficult time trying to comprehend how this statement relates to your argument. Some perspective please?
It's a commentary on how providing isolated islands (app stores) damages the distributed nature of the world wide web. Effectively every app technology is a landgrab by some entity who wants some exclusive chunk of the web with their own rules, usually for commercial gain.
Basically the principle turns the world wide web into another WalMart or McDonald's rather than a vast library.
You keep giving Microsoft's proprietary technologies as bad examples vs Google's open source ones, and keep saying it's the same. It's not. Other vendors weren't allowed to use ActiveX or Silverlight, nor could they help improve it, and fix their bugs.
https://www.mozilla.org/en-US/apps/partners/
As others have said, the goal ultimately with this kind of work is (or should be) standardization. Web tech-based apps really should be able to run anywhere you have a decent browser.
(I work for Mozilla, but not on our Apps work specifically)