Re: Extensions Infrastructure Work
- From: "Jasper St. Pierre" <jstpierre mecheye net>
- To: Erick Pérez <erick red gmail com>
- Cc: gnome-shell-list gnome org
- Subject: Re: Extensions Infrastructure Work
- Date: Wed, 22 Jun 2011 14:34:27 -0400
2011/6/22 Erick Pérez <erick red gmail com>:
> I think I'm late too, to this discussion.
> Simple question first, cause I'm kinda worried with the simple http
> server approach.
> What you need is the browser to talk with the system, and send the
> answers back to the website nope ?
> My point:
> Why don't you eliminate the browser part, if you make a desktop
> application that talks to the website, then the problem is solved.
> (Note: by a desktop application, I mean, sth on desktop, could easily
> be a shell main/default/stock extension that opens the UI you want to
> designand talks to the website using libsoup)
Because i don't want a separate application with its own UI. I could
embed a web control inside the desktop application, but then I've just
reimplemented a browser. A terrible, poor one. So I'm using a real
> And in the webpage you can see the extensions and the version and so on.
> Something like Apple App Store, you can view the store from the web,
> but you interact with it only though the system application they made
> for it.
> With this approach I can think of some issues, but I think is better,
> If an extensions que updated, you can tell the user (through shell
> notifications) and let him choose if he wants to upgrade the extension
I can do this now, too, currently... and I'd do this without the web
browser at all (I'd poll for updates every three days)
> I think that's way safer, and way less work, using the browser
> approach you will have to write browser extensions for
> Firefox/Chrome/Opera and Epiphany, no ?
No. It should work in any browser that supports the HTTP cross-domain
access-control headers that allow us to bypass the same-origin policy,
without native extensions.
] [Thread Prev