At this point to put my foot down on the thread and say: * The official first release will use some form of local HTTP server.
* If you want to make a third-party extension for better browser integration, go for it! I'd be more than happy to modify the browser-side client JS[0] to make it easier for you guys to make your extensions "play nice", too! * I, myself, am not going to make any effort towards coding any browser-based extension. Sorry. I need to get data from the user's session to the browser. The only other hack I could think of doing to get data *back* to the browser was doing a gnome-open with either a #hash or javascript: URL that the page JS could scrape, but in practice, it didn't work. Firefox opened a new tab on #hash URLs and had javascript: URLs from URL handlers and the CLI disabled. I didn't bother testing other browsers, but I don't need to: if Firefox doesn't work, it's broken for me. Mimetypes, URL handlers, and a bunch of other hacks (changing the window title from JS, scraping it from X atoms) are one-way, from the browser to the session, and will not be adequate. If you can think of a technique that allows data to go from the user's session to the browser without depending on browser-specific implementation details per-browser (modifying cookies, HTML5 Storage, extensions) I'd love to hear it. Last night I cleaned up the code and attached a bunch of patches. All of the bugs I filed can be found in the "Depends On" field in bug 652613[1]. Today I'll add some documentation about getting the Django-powered web application up and running, automated tests, and some helper scripts so that I don't have to make a lot of the same test data over and over again. On Thu, Jun 23, 2011 at 8:28 AM, Jesse Hutton <jesse.hut...@gmail.com> wrote: > On Thu, Jun 23, 2011 at 8:16 AM, Olav Vitters <o...@vitters.nl> wrote: >> >> On Thu, Jun 23, 2011 at 08:00:31AM -0400, Jesse Hutton wrote: >> > Forgive me if this has also been considered, but what about using >> > offline >> > storage support in HTML 5? In browsers, it looks like this is >> > implemented >> > with an SQLite database, which theoretically the Shell could talk to as >> > well. >> > >> > And does this really have to be cross browser compatible? >> >> How would extensions.gnome.org know what extensions are currently >> installed on GNOME shell? > > The extensions.gnome.org website wouldn't have to know which ones were > installed. If it's known on the client side, it's enough to limit what can > be installed. > >> >> The thought is that the site knows about it when you visit >> extensions.gnome.org. >> >> As you do not have stuff like ActiveX, you need something to retrieve >> the info. Having something with local storage means it has to already be >> known by the browser. So you'll have to change the local storage of all >> possible browsers... > > There are very good reasons why this type of thing doesn't work across > browsers. If we want to make it so users can install and manage extensions > from browsers, it should be through browser extensions and not a local http > server hack. > Jesse -- Jasper [0] https://github.com/magcius/sweettooth/blob/master/sweettooth/static/sweettooth.js [1] https://bugzilla.gnome.org/show_bug.cgi?id=652613 _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
