Re: Extensions Infrastructure Work

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

On Tue, Jun 21, 2011 at 6:54 AM, ecyrbe <ecyrbe gmail com> wrote:
> Thank you for the hard work you are providing. juste some first questions.
>
> 2011/6/21 Jasper St. Pierre <jstpierre mecheye net>
>>
>> Hey guys, it's Jasper.
>>
>> As part of my work on SweetTooth[0], I'm planning on a bunch of
>> changes to make the user experience for installing, enabling and
>> disabling extensions better. Unfortunately, I'm gonna have to break
>> some stuff unless someone can come up with a clever hack. These
>> changes are not set in stone, but they're what I'm hacking on
>> currently, and I'd like to discuss them to make sure I'm on the right
>> track. Extension developers, I'm talking to you:
>>
>>  * I want live extension enabling and disabling. The user experience
>> is "click a button on extensions.gnome3.org, it takes effect
>> immediately".
>>
>>  * I want to make it safer and more usable for developers to import
>> code and assets their extension directory.
>>
>>  * I want extensions to be smart about their dependencies. For
>> instance, the systemMonitor extension depends on an introspectable
>> GTop, which AFAIK is unreleased, and hasn't been packaged in F15. The
>> only clue users have that something has gone wrong is the Errors tab
>> in the LookingGlass.
>
> Will it be needed to explicitly declare depedencies, or will it be automatic
> when importing?
> can it be dependant on another one, to ensure that it is loaded after?
> (imagine an extension that requires theme to be enabled for exemple)

Both of these are planned, but currently unimplemented, and I'm not
comfortable telling people what it looks like when it's unimplemented.
But my generic answers are "Yes" and "Yes". I'm unsure if I can do
stuff to make PackageKit pop-up, or find the dependent extension
install under the web-UI, we'll see.

>> Unfortunately, in order to do these things, I need your cooperation.
>> I'm going to break some stuff, and I'd like your involvement so that I
>> don't make a wrong decision which means another API break. I'd rather
>> break it all at once and do things right.
>>
>> Let's tackle item 1:
>>
>> == Enabling and Disabling ==
>>
>> I'm going to remove the main() method, and replace it with a new system.
>>
>> You still require one function: init(). It does everything the main()
>> function usually does, except it cannot change *any* Shell state. This
>> is here so that you can set up anything you need to, like gettext
>> silly shell actors. It's guaranteed to be called at most once per
>> shell session.
>>
>
> How does shell state modification will be prevented? i thought that it was
> not possible to prevent code to mess with other shell part?
> or did i missread you?

I won't try to install code that prevents you from modifying the Shell
init(). There's two other deterrents:

One, I'm going on the nature that everybody will play nicely. What's
the incentive for users to modify the Shell during init()?

Two, if you don't do follow the rules, you won't pass review on the
web-UI, which means you have to try harder for people to install your
extension.

>> So, what's used to change the Shell UI? We introduce two new methods:
>> enable() and disable(). Here's some simple rules:
>>
>>  * The Shell will call init(), and then enable() if your extension is
>> enabled when the shell starts up.
>>
>>  * The Shell may then call disable() and enable() again during the
>> same session, but it should never call init() more than once, ever.
>>
>>  * The Shell will not call disable() if your extension is disabled at
>> startup.
>>
>>  * Right now the Shell calls init() even for disabled extensions at
>> startup, but I may change that so that it calls init(), then enable()
>> at first enable. The simplest solution is to not rely on init() coming
>> at the start of the Shell session.
>>
>> For those of you who would like something a bit more object-oriented,
>> you're in luck: init() can also return a state object. All that
>> requires is functions named "enable" and "disable" on that object, the
>> type doesn't matter nor do any other fields. The shell won't touch
>> that object except for calling 'enable()' or 'disable()' on it. If you
>> don't return anything (or return a false-y object), it's assumed that
>> enabl() and disable() are on the moduie itself. Here's a simple code
>> example: For lack of better terms, I'm calling these extensions
>> "stateful", and the module ones "stateless", even though that's a huge
>> lie: both have state.
>>
>> Starting with an improved version of the stock "Hello, World!"
>> extension in the old system[1], we can build a new extension in one of
>> two ways:
>>
>>  1. We can simply rename the main() function to init(), and move the
>> line of code that adds the actor to the Shell to a new enable()
>> method, and add a disable() method that does the reverse.[2]
>>
>>  2. Or we can make the extension return an object that has enable()
>> and disable() functions.[3]
>>
>> If you want your extension to be compatible for old versions of the
>> shell, thankfully, it's very easy: just write a main() that calls
>> init(), then enable(). For the extensions website, I may allow
>> so-called "legacy" extensions with a special method that restarts the
>> Shell, but it would break the user-experience a bit, and it's extra
>> code that I don't think would get used.
>>
>> Checking out the code samples, you may notice an argument called
>> "helper". That's a cliff-hanger for next time, when I want to talk
>> about items 2 and 3. I'd like your feedback on the information I'd
>> provided so far, and any questions on SweetTooth, the web site, or the
>> modifications I'm making would be extremely appreciated.
>>
>>  Jasper
>>
> will the gnome extension infrastructure be officially supported by
> gnome-shell?

Yes. There's no point if it isn't or won't.

> will there be a crypto system to sign your extensions to prevent them to be
> added from unrecognised sources?

I discussed it with Owen, but I think we both think it's not
necessary: as long as we make the automatic system only work from
extensions.gnome.org, we should be safe. I don't want to prevent users
from installing random extensions, just make it harder: a rogue Shell
extension can (unfortunately) do a lot more than a Firefox/Chrome one
right now, so I doubt I'll be making exceptions to that rule until
that changes. If the extension is not on extensions.gnome.org, users
can unpack the extensions and restart the shell manually.

> will there be an automatic update infrastructure?

Yes. The Shell saves a "manifest" for every extension it installs,
which is basically the metadata.json that the user uploaded along with
the extension zipfile, plus some other stuff. It includes the UUID,
among other things. This means that it can automatically update if
there is a newer version compatible with the shell version.

  Jasper