Re: Extensions Infrastructure Work

2011/6/23 Jasper St. Pierre <jstpierre mecheye net>
On Thu, Jun 23, 2011 at 3:59 AM, ecyrbe <ecyrbe gmail com> wrote:
> sorry i only replied to you, not the list and with a lot of misspelling, a
> corrected answer :
> 2011/6/23 Jasper St. Pierre <jstpierre mecheye net>
>> On Thu, Jun 23, 2011 at 3:14 AM, ecyrbe <ecyrbe 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.

Feel free to think of solutions. And what's wrong with a sleeping daemon?

> 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.

I don't think you get what I need: I need the web UI to be informed. I
need to talk to the web browser. Unfortunately, there's only a limited
number of ways to do this. The only browser-agnostic way to do this is
to basically be a website.. that means running a simple HTTP daemon.
It's not meant to be fancy -- it won't look like any other web site
you've seen, it's just some JSON data passed back and forth as a proxy
between DBus and the Web UI. in the case the network is down and the
Shell has crashed, maybe I'll have an extremely simple web UI hosted
on the same daemon that lets you enable/disable extensions, but that's

ok, so you need a json http service to make thing easier, i will not try to disturb you from this design as a lighweight way of doing it is possible.
Can you try to make it a glib-gio asynchronous server embedded inside the shell in _javascript_?
this would make it lithweight. it would follow the reactor pattern, and so will allways answer to requests, i think that this way you don't even need a dbus api to it.
can you think about it?

The shell does monitor the gsettings key, and reacts to it
accordingly. I will check for updates on a cron job, and probably
throw out a notification if I detect it's been updated. I will make
sure that everything is in sync after startup.

>> 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


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