On Tue, Jun 21, 2011 at 6:33 PM, John Stowers <john.stowers.li...@gmail.com> wrote: > >> >> For those curious, the website's partner in crime is >> gnome-shell-extension-tool[2]. There's an option that runs a small >> HTTP server which the web site can talk to. The HTTP server is >> basically a dummy proxy so that the website can talk to DBus. Before >> this lands, I'll rewrite the HTTP server so it's not based on >> BaseHTTPServer and move it into its own script. Maybe I'll rewrite it >> in gjs+libsoup instead, because I'm not aware of any light-weight, >> solid HTTP servers in Python... I don't want to install Twisted on a >> user's desktop machine, even though I'd love to. > > What is missing or wrong with Base/SimpleHTTPServer? Your implementation > in gnome-shell-extension-tool looks to do all it would ever need to do.
To me, BaseHTTPServer is a toy HTTP server. HTTP isn't *that* hard a protocol to implement, sure. I'm just afraid of BaseHTTPServer blowing up. > If you rewrite it in gjs why not host the server in gnome-shell itself? > Is it just the problem of the server going down mid install because the > shell crashes? I may write it in-process, sure. If I did that, I wouldn't have to shuttle over D-Bus and instead call the methods directly. > It seems like in the spirit of a good install experience via the browser > the complexity of this has ballooned to include dependency resolution > (native and other extensions), rollback and upgrades, a local http > server dbus proxy, etc. Thats not necessarily a problem, but it makes me > nervous. This is a project to revamp the extensions infrastructure to allow several things. Live extension installing and upgrading were planned from the start. Owen and I initially discussed how to achieve these goals and had the idea of making a native Epiphany/Firefox/Chromium extension. As an initial prototype for the live enable/disable stuff, I was adding new command-line arguments to gnome-shell-extension-tool for me to test with, when I had the idea of adding a desktop file and mimetype handler to have something to show. It was ugly, and it popped up a Downloads window, but it for the most part worked. I eventually needed a way to return information to the browser that showed which extensions were installed and uninstalled. Dialogue in my head went like this: "The extension metadata is already stored in JSON! I just need a way to get the JSON to the browser! Usually it's done with AJAX, hey, wait a minute, I could set up a magical server to AJAX with as a demo so we get the list before we implement the extension for real.." As I played around with it, I found the HTTP approach more feasible and less ugly than the mimetype handler approach. At first I figured the idea of running a local HTTP server would be a bit ugly, and Owen thought of some security concerns, but there's nothing too critical (or unsolvable) that I know of. The only "ugly" thing from a code perspective is that there's a magic port number: 16269. It's not on the IANA Registered Ports list, so I doubt there's going to be a collision. So the local HTTP server is really just the implementation detail to achieve the installing, enabling and disabling goals. The security and stability systems were also planned from the get-go: we needed a simple way to yay/nay extensions, and maybe code review, and we need a way to disable extensions if they crash your Shell. Rollbacks seemed like a good way to do this if you had an extension upgrade recently. > Personally I would ignore or prohibit inter-extension dependencies, and > perhaps only allow dependencies via checking for typelibs. I would put > the extension browsing/install/upgrade completely inside the shell or > completely outside of it. It's something I'd eventually like to do, but most definitely will not be in the first release. > John > > p.s. If you claim extensions.gnome.org please place this at > http://extensions.gnome.org/shell/ as IIRC there is another SOC project > (or at least a plan) for a libpeas online extension story that might > result in websites at > http://extensions.gnome.org/appname_that_uses_libpeas/ > Thanks for letting me know! I had no idea this was happening. I additionally assume I don't have any control over where my application finally goes: this is a sysadmin decision, so whenever I use "http://extensions.gnome.org"; or "http://extensions.gnome3.org";, I'm just talking about the website. I don't have any other good label for it: maybe "SweetTooth-Web" or "SweetTooth-WWW"? Garret, I didn't want to steal your thunder, promise! Jasper _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-shell-list
