FUEL/firstrun case fuel

Analysis of Extension Services in Fuel, the FirstRun Extension Case

This work is not part or endorsed by FUEL team yet. It aims to be. Please ping marcio if you have questions. Also if you can identify the need of Extensions that can be served as Services your input is very welcome. Marcio

Scope, Motivation, and Goals

• FirstRun, an extension for developers; Simple to use;
• FirstRun, how can this fit in FUEL;
• Contribution to FUEL project;
• Contribution to future of extensions framework in Mozilla;

Introduction

An important goal in FirstRun is to serve an extension developer with a first run function. Because FirstRun is also an extension, it is important to differentiate from an ordinary extension. It can be understood as an extension service, or an extension that could be used by other extensions. This document serves as a space to identify scenarios of use for FirstRun and how it relates to extension toolkits, in particular with FUEL. Please file comments to mgalli@mgalli.com

Brainstorming Proposal

FirstRun could be considered an extension written in compliance with FUEL. So could serve itself to other extensions via an organized and free of trouble environment. For the end-developer perspective, an example of an application stack would be:

• Developer has FF;
• plus Developer has FUEL;
• plus Developer integrates FirstRun (xFuel?);
• plus Developer talks with FirstRun via FUEL;

In this model, the FirstRun would expose itself ( registration, its functions, and possibly a rule system ) with Fuel Application management service. Then its life cycle functions could be exposed to the end-developer. If an end-developer plugs it ( what means plug? install? bundle ship? ) then its functions could be used via fuel organized execution environment.

Concrete Advantages for now:

• FUEL manages Events; namespace management, the priority order, which runs first, the ruling system;
• Fuel would present itself ( Application ) as the broker;
• Developer uses Simple Event system to stablish communciation / async / sync / possible future remote trusted events;
• Developer could have a FUEL Debug view of events;

Challenges

• UI Rules - Which templates and how to set to define the appearance;
• UI style - developer to set style to FirstRun;
• Localization - developer has to tell FirstRun to use a given Locale;
• Would FUEL be able to keep track of the Apps life cycle all together?
• What are the implications of this model? Could FUEL be simply a broker? so extensions can talk each other?

Further possible advantages:

• Automated profiler for Extensions
• Dependency viewers
• Automated tests
• Means to import a Localization Bundle dynamically over an extension