sorry i only replied to you, not the list and with a lot of misspelling, a corrected answer :
2011/6/23 Jasper St. Pierre <jstpie...@mecheye.net> > 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? > > i think that you can check this buy other means. i didn't say that it's easy, but i think that it's better than than a daemon that will sleep 99,9% of the time for just this. if something diseable a gsetting key, you could monitor it in the shell, no? And just anounce that directly using dbus isn't allowed. if that's not sufficient, you could add a cron job to check that everything is ok. if the shell have crached, you just check that everything is in sync at stattup. > 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. > > it's easiest, but overkill (only my opinion) for such a tiny functionality. But anyway, if you really want it, couldn't you add an asynchronous httpserver integrated in the shell with gio (no need for aanother running daemon). ps : again sorry, english is not my native langage. > > 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
