Re: Extensions Infrastructure Work

[Tim Cuthbertson <tim gfxmonk net>]

On Wed, Jun 22, 2011 at 5:59 AM, Jasper St. Pierre
<jstpierre mecheye net> wrote:
> On Tue, Jun 21, 2011 at 7:40 AM, Jasper St. Pierre
> <jstpierre mecheye net> wrote:
>> 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.
>
> I must have been really tired last night, these answers are useless.
>
> Extension dependency management is tricky... first, for
> auto-dependency-installation, they must be on the extensions web-site.
> The harder part is versioning.
>
> Extensions will need to explicitly list their dependencies. I don't
> know enough about PackageKit, but I'd like to say, "can you look for a
> GTop.typelib anywhere for the correct architecture", and hopefully it
> will work, even if the package puts it somewhere un-standard, but
> that's Richard's question to answer.

Sorry if I'm late to the party with this suggestion, but I think this
is where using zero install[0] for extensions would shine:

 - feeds that contain only JS (i.e no compilation required) are
trivial to create.
 - built-in GPG signing of feeds
 - version requirements are supported for dependencies (before, not-before)
 - you can depend on other extensions, or on arbitrary packages. These
can be other (vanilla) zero install feeds, or they can be feeds that
are a wrapper for a system package
 - system packages can have multiple names for a given zero install
feed. This will allow you to depend on fooBar for fedora, but
libfoo-bar on debian
 - 0install uses packagekit to resolve & install system packages, so
the experience should be fairly straightforward for users
 - doesn't require root access (unless system packages need
installing, obviously)

[0]: http://0install.net/

I'm working up to releasing an extension that requires my own mutter
fork (for now, I hope that won't always be the case), and 0install is
the only way I can sanely do so. It allows my extension to
 - have dependencies
 - not mess with the system version of mutter
 - work cross-platform (not a big deal when fedora is the only distro
with GS, but will become more important later).

I'd love 0install to be used for gnome-shell extensions, and I'm happy
to help out with whatever I can to make that happen.

> If it's not trivial, then nope, it's on the backburner for now.
>
>>>> 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
>>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>