> > > > 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?
A bit of an explanation because I don't think you quite understand this yet; 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 [1] 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 anyway. 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. John [1] I would have done the whole thing in a separate application and sidestepped these problems, and likely introduced others. _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
