On Thu, Jun 23, 2011 at 3:14 AM, ecyrbe <ecy...@gmail.com> wrote: > sorry, but i think that i miunderstood you or the contrary i don't konow > (sorry english is not my native langage). > but i understood that you need an http daemon just to keep the state of > installed extensions in the browser in sync with the shell. > doesn't a cokie based system should theoycally worj? if you could provide > something based on cokies (even if it's less elegant solution) > i think that it's a better one than haviong an http daemon. > Am i wrong here? sorry if so.
No. What if something else (gnome-tweak-tool, the shell's crash handler, another shell extesnions etc.) disables extensions by editing the gsettings key or calling the DBus methods themselves? How do I make sure that a user can't install an extension that their shell version doesn't match up with? I need a way to get data to the browser. An HTTP method is, as far as I know, the only browser-agnostic solution, and the easiest to implement. > 2011/6/23 Jasper St. Pierre <jstpie...@mecheye.net> >> >> On Thu, Jun 23, 2011 at 2:29 AM, ecyrbe <ecy...@gmail.com> wrote: >> > Hi jasper... are you really sure you want to have an http daemon just >> > for >> > updating an extension? >> > why can't you have : >> > - a cron task for polling update check >> > - get the shell write to a cookie write the currently installed >> > extensions >> > - use a javascript code for analysing the cookie information and showing >> > accordingly the information on the browser >> >> The HTTP daemon isn't for updating extensions, it's the DBus proxy for >> installing, enabling and disabling extensions. I've detailed above why >> it's necessary. >> >> > because having a webserver just for this is a terrible idea... you can >> > use >> > already provided running system daemons to do the job, >> > i really don't think that you need another one. i think that a http >> > server >> > is overkill for this job. >> > >> > can't we have a litle brainstorming on this list to come with a better >> > solution? >> > >> > 2011/6/22 Jasper St. Pierre <jstpie...@mecheye.net> >> >> >> >> The problem isn't getting data from the browser to the Shell, it's >> >> getting data from the Shell to the browser. >> >> >> >> mime types, URL handlers, and thousands of other clever hacks don't >> >> allow two-way communication. I want to have a button that says >> >> "Enable" or "Disable" based on the current state of the Shell. None of >> >> those hacks let me do this. >> >> >> >> Building a server (could be WebSockets) that the browser can talk to >> >> is the only browser-agnostic solution AFAIK. >> >> >> >> Other solutions include modifying the cookies/HTML5 storage of known >> >> browsers or a native extensions. >> >> >> >> On Wed, Jun 22, 2011 at 3:52 PM, Olav Vitters <o...@vitters.nl> wrote: >> >> > Random thoughts: >> >> > 1. MIME type still seems nicer >> >> > 2. Would it be possible to have a custom URL handler? >> >> > >> >> > -- >> >> > Regards, >> >> > Olav >> >> > >> >> >> >> >> >> >> >> -- >> >> Jasper >> >> _______________________________________________ >> >> gnome-shell-list mailing list >> >> gnome-shell-list@gnome.org >> >> http://mail.gnome.org/mailman/listinfo/gnome-shell-list >> > >> > >> >> >> >> -- >> Jasper > > -- Jasper _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
