2011/6/22 Erick Pérez <erick....@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 browser. > 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. > Erick > _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
