Re: Extensions Infrastructure Work
- From: ecyrbe <ecyrbe gmail com>
- To: John Stowers <john stowers lists 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 11:48:57 +0200
thank you john for the bits of history of the design.
i do know about server programming, as in fact it's my job to make high load servers in c++.
i also understand the design better and the solution you try to provide.
as i said. you can make the server lightweight inside the shell, i don't think people would complain as this would make it a lighter solution than a separate daemon.
The problem with a separate daemon, is that you end up using a process to do nothing 99% of the time. integrating it in the shell would make it :
- leightweight -> you only add a listening port to gnome-shell.
- integrated -> you don't need to add a dbus api to control extension enabling/disabling
- easy to implement -> you only have to use libsoup asynchronously, no threading use
- no memory overhead -> it's integrated in the shell , you don't have to allocate a new stack for it
so, why not integrate it? why would people complain ?
2011/6/23 John Stowers <john stowers lists gmail com>
A bit of an explanation because I don't think you quite understand this
> 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?
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