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.li...@gmail.com> > > > > > > > > > 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
