Re: Extensions Infrastructure Work
- From: John Stowers <john stowers lists gmail com>
- To: ecyrbe <ecyrbe gmail com>
- Cc: Olav Vitters <olav vitters nl>, gnome-shell-list <gnome-shell-list gnome org>
- Subject: Re: Extensions Infrastructure Work
- Date: Thu, 23 Jun 2011 21:31:01 +1200
> 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
> Can you try to make it a glib-gio asynchronous server embedded inside
> 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?
A bit of an explanation because I don't think you quite understand this
The starting point for this design was 'make it easy for users to
install/remove/upgrade extensions'. Jasper has decided that following
the firefox/chrome model (where people are used to doing this task from
inside the browser) is understandable for the user and can be done
nicely. Fair enough 
Once committed to doing this in the browser, one needs to pass data
(such as the information on which extension to install) from the browser
to the users desktop.
One approach (which was ruled out because the user experience is not as
nice) is to download a special file (mimetype) and have a special
program handle this and install the extension (this was the mimetype
handler approach discussed earlier). The chosen approach was to instead
make use of the cross-domain JSON request capabilities and interact with
the shell (such as to query the installed extensions, etc) more
directly. This requires a HTTP server.
Once committed to a HTTP server, the question is where does it live. In
the shell or separate. For this implementation it lives as a separate
application which basically proxies the HTTP JSON requests from the
extension website to the shell over DBus. It is theoretically possible
to build a HTTP server in the shell (perhaps using libsoup
+introspection) and do things this way, but then I am sure people would
complain about a HTTP server in the shell.
Things like live enabling/disabling/installing needed to be implemented
Jasper, regarding updates, the shell could poke the HTTP server to check
for updates, or check for updates directly, and then tell the HTTP
server to download and install them. No need for a cron job as the shell
is already running.
 I would have done the whole thing in a separate application and
sidestepped these problems, and likely introduced others.
] [Thread Prev