I think the file format itself is the most trivial aspect of this whole thing. Even if you'd roll your own, you probably could cobble together some kind of XML/JSON based copy of the message DB diff within hours (or just use RSS).
The primary reason this is Chrome-only is because other browsers don't yet have complete implementations of relevant specs (for example the FileSystem API: http://dev.w3.org/2009/dap/file-system/pub/FileSystem/). I can't make any promises on the team's behalf, but I personally would like to see it working on Firefox as well at some point.
I'm curious what y'all are using the FileSystem API for and how you're using it. If you wouldn't mind talking about that (or have other people on your team that would be interested in talking about it), drop me an email at <my-hackernews-username>@mozilla.com.
It looks like they're leaving out everything in the spec I linked above. Currently this is the only way to persist File objects locally, although it looks like they're planning to make that possible through IndexedDB instead.
Gmail is clearly more of a beta than a functional product (namely attachements don't seem to work), but the biggest question/implication of this change I see is evaporation of any business model (as in 'the ads are gone').
Besides that - I like the UI a lot, but for any offline access to make sens it has to be rock solid (which this obviously isn't).
Attachments should work, with a few caveats. Due to some annoying quirks of the HTML5 FileSystem API, there's a whitelist of supported file extensions. This includes everything useful we could think of, but it's not exhaustive.
The specific requirement for being whitelisted is that it shouldn't have a MIME type that Chrome wants to open inline. Give me a list of extensions that you'd like to see supported and I'll see what I can do.
Screensavers are just special exes on Windows and are commonly used as viruses. Might be better not to whitelist that one and instead convince people to zip them up if they really want to send them.
I think that there are a fair number of mail filters that block .scr entirely, anyhow. In that respect, they're similar to .bat, .vbs, .wsh and the like.
Alternatively, you can just offer to automatically zip those for the user. Actually, that might be a good idea for all unrecognized files because it avoids a lot of weird problems with funny extensions that are automatically blocked.
As a developer who sometimes have to send a zipped project with a compiled build inside, I find this "feature" extremely annoying. I usually end up renaming the file from .zip to .lol or similar.
My experience was the opposite, unfortunately. Why can't the offline gmail application use the same UI as the online one? To me, that would be the obvious way of doing it.
Adblock? Please. POP / IMAP - valid points. But this is slightly different - it's a product they designed from scratch, control the UX etc. Still - no business model.
Perhaps they figure it is better for users who need to reach their email while offline to use Google's offline web app occasionally instead of moving to POP/IMAP altogether.
in an offline mode how would you monetise offline ad clicks? google's business model is based on ctr not cpm. are you thinking of caching ads/pages too?
I don't imagine they need to monetise this part. The offline app simply makes Gmail even better and gives those who use desktop clients one less reason to stick with them. As a result of this more people will end up using the normal online app and therefore clicking more ads.
The thing is - with the new interface, that is perfectly accessible through the browser AND makes sure your offline is in-sync why would people carry on using the regular version?
Deck is doing that somehow (caching ad impressions at least) - so it is an addressable issue. However - this app works both in online and offline mode, so my point was not really touching the offline ad problem - thanks for pointing it out.
offline gmail is disappointing. it's basically the tablet version, meaning the consistent google interface is lost, labs features are lost, keyboard shortcuts are lost, theming options are lost, google nav bar is gone, etc...
offline docs and offline calendar is not available but from the description, it sounds they have proper implementations.
What a massive failure. I wonder if they realized they weren't going to hit the deadline so they decided to do a quick implementation with the tablet app. The old rumors that Gmail is a massive spaghetti mess must be true. Let's just hope they're actively rewriting it and don't think this is good enough.
One thing we learned early on was that making any existing system (especially one as big as Gmail) work offline had some very difficult, fundamental issues. The biggest of these is that everything that normally happens server-side must also be able to happen client-side when there's no network connection.
This is a problem not only because there is a lot of server-side complexity in Gmail, but also because it changes all the time. New features are added, old behavior is changed, and if the offline code path isn't changed along with it, things have a tendency to break horribly. The only solutions to this involve having every Gmail engineer modify the offline code path whenever they touch the online, which is a large burden that we weren't willing to lay on them.
As a tablet user, I actually like this; when I got a honeycomb tablet, I realized I had come to miss the split-screen view after several years of using Gmail...not that I want it to turn in gOutlook, but there are definite advantages.
On the negative side, it's very weak that there are no formatting controls in this version. I miss them on the tablet side already, which means that messages sent from that device necessarily have a different signature from those sent from my desktop. It's not necessary or even desirable for mail recipients to know I was using one device or another. Some people like to signal that they are on the go with 'sent from my phone' or the like, but I would rather have some basic editing functionality, and this would not be hard to add. On a tablet it's annoying, on the desktop or a laptop where I might need to work offline it's unforgivable. On the up side, this is a good starting point for building an editing/configuration interface that could find its way back towards the tablet space. With wide-format screens the norm nowadays, I was struck by how much more pleasant the panel experience was on my desktop monitor and could see myself switching to this from the page+widgets approach of existing gMail, which is beginning to feel very long in the tooth.
This goes double for Google Docs, although it's slightly off-topic. I like working on my tablet a great deal and find I can type surprisingly fast even with the on-screen keyboard as opposed to an external one. But Google Docs on a tablet is so unusable that every manufacturer ships with some open-source office suite to make up for the deficiency. since Android does not have the same mind/market share as iOS/iPad, Google needs to offer compelling software alternatives. In many respects it already does so; but productivity tools are noticeable by their absence or abridgement. A minimally-capable version of Google Docs made sense on a smartphone, but on a full-size tablet it's absurdly self-defeating, and inimical to a corporate or academic environment. I would pay for a 'power user' tablet version of core apps like gMail and gDocs. The fact that there is no easy way to leverage forms into an Android clipboard/data-entry interface is a major missed opportunity.
This really needs to see some movement in tandem with the upcoming Ice Cream Sandwich launch. I know both Docs and Android are outside of your remit, but hope you could circulate these concerns in the cafeteria, so to speak. I mention this here because *@gmail.com is increasingly acceptable as a professional address, but this will only last so long as the tools cater to the needs of professionals.
I think the difficulty is that none of the technologies that you are using were designed for building software applications, but for showing text and images on a screen.
In other words, there is a perfectly fine solution for offline G-mail, it's called "e-mail client".
Actually the problem may be that OS user interfaces, for all their native functionality, have not kept pace with browsers at showing text and images on a screen. Hypertext is an innovation that is hard to ignore.
Native UI is vastly more powerful compared to HTML and CSS, which were designed to display web pages, not widgets and controls.
In fact I don't understand what kind of experience you have to say something like that. If you were a web designer you would know that the web UI is a painful to use hack.
If you were a mobile/desktop developmer you would know that both types of UIs are better at showing pretty much anything on a screen - including a browser engine.
I can't comment on unannounced engineering efforts, and I certainly didn't mean to imply anything about them.
All I can really say is that if they wanted the primary Gmail client to support offline, then it's my personal opinion that the only tenable way to do that is by having a single code path. Whether there are plans to actually do this I don't know and couldn't talk about if I did.
Maybe they just want a solution that people can use RIGHT NOW. What's wrong with that?
I'm thankful for Google providing this solution though I'm hoping for a better one in the future.
Calling it a massive failure is just mean-spirited.
You call yourself an "aspiring entrepreneur" but I don't think you understand what it means to be one and actually build stuff. If you do, you wouldn't be making comments like that.
I'm a programmer and I've received much harsher words about stuff I've written. Maybe I'm hypocritical, but I feel less of a need to bite my tongue with Google than with a HNer's weekend project. The fact is that they've been promising this feature since they discontinued Gears over a year and a half ago and to then fail in this way is both disappointing and insulting to me. It's insulting because I'm passionate about the web and I know that web applications can handle offline just as well as native applications, and their slowness to add support to their most important products contradicts that belief. And it's insulting because they've released something so that they can say they have Offline Gmail when this barely counts as that. Having separate apps, with separate UIs, and separate ways of launching, for an online and an offline version is not a customer-centric decision; it's a face-saving PR decision.
"It's insulting because I'm passionate about the web and I know that web applications can handle offline just as well as native applications, and their slowness to add support to their most important products contradicts that belief. And it's insulting because they've released something so that they can say they have Offline Gmail when this barely counts as that."
Insulting? I don't get it. What are you entitled to? That is such an arrogant statement. Can I ask what have you done to the web community since you are very passionate about it?
Showing passion is not about putting other people who actually build things down.
You have to realize that Google may be a big entity but it is still a group of individuals.
You have read the comment from the Offline team and they have a good reason why they can't do it right now.
Gmail is probably Google's biggest product after search. It's also been around for a long time, so you do have to keep that in mind.
I would presume the Gmail team are still working on offline, but Google prefers launch + iterate, rather than waiting for things to reach a "finished" state. This was the quickest way to get people to an offline Gmail product.
DISCLAIMER: I'm an intern at Google, but have no information about these products apart from what is publicly known.
This comment is completely out of line. Trashing something pretty decent on its launch day is not a sign of elevated or discerning taste, it's a sign of someone who does not understand how hard it is to ship something.
Having some kind of offline Gmail (and Docs and Calendar!) is indeed a VERY big win, even if it doesn't have every conceivable feature on day one. It makes Chromebooks that much more appealing.
Ok, the UI and launcher are different. That's not "massive failure", that's minimum viable product. Yeah, even Google does that.
Since you develop for the Chrome app store, did that particular comment advance your cause? Are there particulars you could point them toward, or identify things they should keep in the total re-write you hope for?
I don't hope for or care for a total re-write; that's up to them. But they should be able to cache all resources with AppCache. They should be able to cache recent messages with LocalStorage. These are not new technologies; they've been around for a couple of years at least. Here's Google discussing their use of AppCache in Mobile Gmail well over 2 years ago.[1]
Yes these technologies have been around for several years. Unfortunately none of them are stable/reliable/easy to reason about.
WebSQL (SQLite) has been ignored by Mozilla, on the stated basis that an independent implementation of WebSQL would be too difficult to build. They advocated that a database designed by committee would be better for the web than the most widely deployed database in the world. They deprecated WebSQL before IndexedDB was given a chance to prove itself. Unfortunately they also said that anyone could build SQLite on top of IDB if they chose to. Firefox have implemented IDB on top of SQLite. IDB is at least an order of magnitude slower than SQLite.
LocalStorage is capped at approximately 10mb and there are no quota apis to adjust this. It is not likely that this will change and there has been discussion on the Public Web Apps over whether LocalStorage should also be deprecated in favor of IDB.
ApplicationCache works well but it's designed for caching code and html and it's not an alternative to IDB.
IndexedDB is high-level and "to-do list" friendly. It is not primarily focused on providing library authors with performant low-level storage primitives (BTree, KV) with which to work. The specification is exceedingly complex and so is the API. Chrome has implemented IDB on top of LevelDB which is a terrific storage engine. Exposing something like LevelDB directly would be more useful and make for a powerful, flexible API to boot. IDB has problems with inadvertently capturing application state bubbles. Indexes must be predefined and then migrated at the database layer, the application has no say over indexing. I'm not sure if IDB supports indexing object array values yet. IDB claims to support MVC yet most implementations cause writers to block readers and even readers to block other readers.
Edit:
Mozilla don't plan to support the FileSystem API.
It's not clear that all browsers will provide persistent storage guarantees. At least Mozilla have said that they may treat client-side storage as evict-able at the discretion of the user agent (as opposed to user), rather than as persistent storage. I'm not sure if the specifications have been updated to enforce some kind of guarantee on the part of user agents.
Well, there's only about 500 users with 2000 or more karma, but I'd still say that's roughly the baseline for "reputable": you've stuck around and made some contributions.
In so far as this site only seems to keep the interest people who are interested in this scene, that seems like one of the many types of folks a googler working on this would want to do right by. And, it would seem to me that his comment wouldn't exactly make a googler feel a sense of accomplishment. Maybe you're right, they might dismiss it. But there's a non-zero chance they felt a little worse, their lunch didn't taste quite as good after reading that. And if that's the case, my point to him was to ask what purpose did that serve? Because it didn't seem like a nuanced criticism.
Geez, I certainly don't want anyone to feel bad about themselves or have a bad day because of some flippant worthless comment I made. My opinion really isn't that important.
It's still August. Stuff doesn't get rushed out until the end of a quarter when OKRs are looming. At that point you can push any old thing and get away with it.
In other words, check back in a month to see even worse.
At the risk of sounding like a troll, which I'm genuinely not trying to be, this problem is more than solved when using Outlook with hosted Exchange or Office 365.
That works absolutely perfectly over unreliable connections and in offline mode.
It's also been around for nigh on 10-15 years now.
Outlook with hosted Exchange or Office 365 is a solution which suits some people. However, there are many for whom the Gmail, Calendar and Docs combo works better. Consider money, sharing and other factors and you'll see why the "been around for nigh on 10-15 years" doesn't mean much.
Money - if you know what you are doing, you get the partner action pack which costs me 259 GBP a year (22GBP/month) and gives me 10 seats of a lot of cheap software including Windows 7 Pro and Office 2010 Professional [1]. Office 365 is 4 GBP per month per user which costs me less than my monthly toilet roll bill.
Sharing - that's the point of exchange and outlook. It works and it supports all the relevant modern interoperability.
There's huge difference between easy access costing nothing extra and "knowing what you are doing" and 259GBP / year. For you, the setup you have chosen suits probably very well but please understand that it's not for everybody. I bet there are many people who would enjoy offline features and do not have the money and know-how for Outlook with hosted Exchange.
Relevant modern interoperability is a very loose concept. There are many types of sharing. Consider that with Google docs you can share a document for example as a web page for free.
Other factors such as already using one Google product such as Gmail and Google Contacts and the synergy of using other Google products.
But yes, I agree with you partially that this problem is solved. Just not for everybody.
have you read the 1st paragraph of the page you linked to ? That seems to exclude a lot of use cases:
"These software licenses are provided for use at your company’s primary business location only and must be used only for internal business purposes, conducting demonstrations with your customers, and training your employees. These licenses may not be used for direct revenue-generating activities (such as website or e-mail hosting, or custom solution development for monetary compensation). They also cannot be resold or used for personal reasons. "
>gives me 10 seats of a lot of cheap software including Windows 7 Pro
That is correct. It depends how you interpret it. The full terms are delivered during the signup process. The valid interpretations are (all confirmed by MS partner support on the telephone before I signed up)
a) I am a registered sole trader as are most startups and freelancers in the UK so it's covered under business use as there is a trading name. Training, certification, continuous product evaluation for clients and integration testing are suitable cases for personal use but do not include leisure (ie dont run a media centre with a license).
b) You can use the licenses for any purpose on workstations, server licenses for development, on machines which are portable and can be taken off site which are registered at the licensed location (confirmed by MS Partner support) and the windows 7 licenses can be used against OEM machines shipped with lesser versions of Windows 7 using AnyTime upgrade. You can run your fileserver and internal exchange with the license if you desire as long as you do not resell.
c) You should never bother hosting on your own licenses - that's what Hosted Exchange, traditional hosting and Azure are for. You'd end up paying for the kit anyway. If you don't use any of that tech, ignore it.
It makes financial sense when you consider the cost of a few windows and office licenses and a fileserver for a small IT business and it's 100% legitimate.
I think the gap will never close myself. I think it will hypothetically close and then thanks to net neutrality falling over and providers grabbing cash over bandwidth, we're going back to a thick client model.
It all goes in a big cycle which I've seen 2-3 times now in my life.
I wonder if someone could take the idea of QWK and build it into modern web forums / email systems.