BTW, I'm the author of this software. So I've been trying to figure out how to save things locally for awhile. I realized that HTML5 has a File System API which in Chrome 9 can FINALLY write to the local SANDBOXED environment. This feature is planned!!

This has potential. I asked for this very thing about two months ago and surely someone is delivering. http://news.ycombinator.com/item?id=1980806

How far do you plan to go with this? You could certainly make a buck or two if, say, you start offering a premium IDE with auto-complete, server-side compilation, etc. Not sure there's a big demand for this. Maybe you could sell this to enterprises and they could just deploy a lots of thin clients--save some cash on powerful workstations--and can log in from anywhere to develop and compile the code server-side and seamlessly deploy. But I'm just thinking out loud now. Best of luck.

FYI, I meant that the user should be able to test out your app without having to enter in any info, even if it means that saving is disabled.

I started using CouchDB to save locally, or anywhere. It seems to be working out well. What are your plans with the future of this ide?

I plan to utilize the Dojo's data API as an abstraction layer on top of many different kinds of drivers. I also have thought a bit about what sorts of SERVER side integration this can have - with the potential of websockets, I can see a RESTful git/hg server to be a next logical step!

The Dropbox API supports the standard OAuth web flow which just requires you to have an active session on dropbox.com. I put in a feature request so hopefully soon the extension wont ask for passwords anymore.

As a work around for what? How does having a hidden dropbox.com frame stop the extension from asking for passwords?

As a solution to the bug you mentioned ("The Dropbox API supports the standard OAuth web flow which just requires you to have an active session on dropbox.com"), where you say that you need an active session on dropbox.com to use Dropbox's OAuth API.

Judging by your response, it's clear that there isn't a bug, and you either just don't know how OAuth works or you don't understand what an active session is. OAuth doesn't require an active session on a website, and an active session is having a page loaded in your browser.

> Judging by your response, it's clear that there isn't a bug, and you either just don't know how OAuth works or you don't understand what an active session is. OAuth doesn't require an active session on a website, and an active session is having a page loaded in your browser.

The OAuth web flow requires an active session on dropbox.com. Without an active session Dropbox can not verify who the user is.

You still didn't answer my question about how a frame would help. Iframes should never be used to to embed OAuth provider authorization pages and embedding dropbox.com in general would be pretty useless if the user does not have an active session open.

As far as active sessions go dropbox.com is going to have two kinds authenticated and anonymous. Since we are clearly talking about access to users Dropbox accounts the only type of active session that would be useful would be authenticated.

> You still didn't answer my question about how a frame would help.

I thought you were saying that you couldn't get the Dropbox API authenticated using OAuth working unless you had a continuous active session on dropbox.com. Sorry for the misunderstanding.