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.
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.
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.
Worker<->UI communication is asynchronous, and has additional limitations (only copying, only JSON-able data), so synchronous worker API in many cases would just shift complexity elsewhere.
In part. It makes conditional, nested queries much simpler, however, when you don't need to nest async callbacks 20 layers deep.
I understand that having a synchronous API would mean more people would use it. But honestly, I see that as their problem. A fair number of queries, such as "select * from your_table where id = ?", are useful to have synchronous as an option, and should perform quickly enough to be invisible. And synchronous can easily be made asynchronous, but the other way around is essentially impossible without any Thread.join.
It's not actually true that Sass and Less have the same features. Each has some features the other doesn't, with Sass having substantially more than Less. Notable examples include the ability to use variables in selectors, the @extend directive, and a wealth of useful built-in functions. It's because of these and other features that Compass can be built on Sass, where it couldn't be built on Less.
That's the difference between reference documentation and introductory documentation. You go to reference documentation when you want to look up the details of something you already know; you go to introductory documentation if you want to learn it for the first time.
Okay sure, but how do you get from the introductory docs (which are far and wide, as well as lacking in quite a few areas) to reference documentation. I can see how ruby-doc can be a good resource but only for those that know the language and know what they should be looking for, even then though sometimes docs like python's are better references.
there are also two great books, the agile rails book, and the rails way. They will get you started, and may be 90% of what you need. The docs are good for the rest.
One thing though, we're comparing apples and oranges; the docs for a web framework vs the docs for a standard library. Are the django docs similar to the standard lib docs?
I'm not trying to dis python, I really like python and use it whenever I need to do mathy stuff with numpy and scipy. Most other things I do in ruby.
