Re: Extensions Infrastructure Work

[ecyrbe <ecyrbe gmail com>]

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.
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 <jstpierre mecheye net>
>>
>> On Thu, Jun 23, 2011 at 2:29 AM, ecyrbe <ecyrbe 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 <jstpierre 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 <olav 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