Re: Extensions Infrastructure Work



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 hutton gmail com> wrote:
> On Thu, Jun 23, 2011 at 8:16 AM, Olav Vitters <olav 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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]