Re: Extensions Infrastructure Work

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.

> Erick

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