Re: Extensions Infrastructure Work

["Jasper St. Pierre" <jstpierre mecheye net>]

On Tue, Jun 21, 2011 at 6:33 PM, John Stowers
<john stowers lists 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