I have been planning some changes related to AMD modules directory
structure:
(actually keeping the structure as it is, just move some modules around).

Here is the set of changes I'd like to do:
* firebug/firefox/annotations -> firebug/chrome/annotations
* firebug/firefox/menu -> firebug/chrome/menu
* firebug/firefox/privacy -> firebug/chrome/privacy
* firebug/firefox/system -> firebug/lib/system
* firebug/firefox/tabWatcher -> firebug/chrome/tabWatcher
* firebug/firefox/xpcom -> firebug/lib/xpcom
* firebug/firefox/window -> firebug/chrome/window
* firebug/firefox/firefox -> firebug/chrome/firefox

Now the question is how to preserve compatibility with existing extensions
that are using Firebug modules? I don't think there is many such extensions
already so, at this moment it could be ok, but I am sure we'll face
something like
this in the future.

Do you have any tips how we could preserve this?

Could we somehow configure the loader to look for specified
module at a new location?

Honza

Since we're already expecting to make bigger changes in 1.10, that possibly
break other parts extensions already make use of, I think it's fine to move
them.

The only thing we should do, is to set up the extension migration page I
already mentioned earlier and keep it up-to-date. Also such changes should
be done early in development, so extension developers have enough time to
adjust their extensions.

To avoid such problems in the future, we should discuss where additional
modules should be put before we add them.
Also we should clearly define what each category is meant for. So e.g. what
should be put into *chrome* and what into *lib*?

Could we somehow configure the loader to look for specified module at a new

We could define a mapping. Though I would avoid this, if possible.

Sebastian

This touches on an important point that CommonJS and specifically myself
have been working on and relates to the need to break modules into
packages and have packages map external dependencies into their namespace.

A quick fix would be to have a "compat" or similar directory that
contains the old modules (at old paths) and in the modules simply log a
deprectaed message and load and export the module from the new path. The
loader can be patched to look for the path in the compat folder before
proceeding to the "new" module tree as this runs in chrome and we have a
file API.

The long term solution is to break firebug functionality into packages
and provide an extension API interface package. If the interface needs
to change, a new major version for the interface package can be shipped
and older major versions of the interface package can map to the new
interface. I am working on a minimal loader that we could use instead of
the RequireJS based loader that provides what is necessary and will
allow for loading of AMD formatted source files.

The browser version already works: https://github.com/sourcemint/loader-js

If there is interest I would love to put together a proposal to break
firebug modules into packages and provide a patch to use the sourcemint
loader instead of RequireJS in firebug. With this change anything
generic in firebug that would be usable in other extensions or web pages
would become usable quite easily (because we can map the dependencies
for a package to an environment-specific adapter). We could target to
have this in for 1.11 and I am willing to do the work to make this change.

Let me know. I hope to have a jetpack compatible Sourcemint loader
working within the next few weeks.

Christoph

P.S. RequireJS only has one flat namespace per runtime that all packages
map into. The Sourcemint loader (CommonJS + Mappings + AMD adapter)
maintains a namespace per package where dependencies are mapped by
configuration or dynamically.

I see.

So, "The loader can be patched", means:
RequireJS doesn't support such solution currently, correct?

Yep, I like this idea. If I understand correctly, the API interface package
could
be similar to what we have done to preserve the old FBL global object (also
for back comp).

It's the FBL object implemented as AMD
http://code.google.com/p/fbug/source/browse/branches/firebug1.10/cont...

Sounds really great and I thing it's also great timing. I have already had
a quick discussion with Harutyun to replace RequireJS, with something
smaller and faster.

Can you explain more what it really means for Firebug's directory and
logical
structure to have more "packages"? What kind of changes this would
represent?

If I understand correctly, Firebug is currently implemented as one package,
correct?
For example, we want to use Orion text view in the Script panel content and
so, all Orion
related files could represent an independent package.

Sounds great!

Notice that we have just started 1.10 and so, we could consider to have
this in it. The advantage is that since 1.10 we want to encourage developers
to use AMD in their extensions. Also note that reasonable changes for 1.10
are planned and if we are successful it could become 2.0

 Honza

Let me know. I hope to have a jetpack compatible Sourcemint loader

So, I think that the first step is to have the proposal with more details.
As soon as you have it I can do immediate review and provide detailed
feedback. Any time estimate?

Honza

Yep, I know, I was more interested in the right way how to solve this in
the future when there are already Firebug extensions based on AMD.

The only thing we should do, is to set up the extension migration page I

I don't think it should be the *only thing to do*, but I have already
created the page and I am regularly updating it (e.g. the list of module
changes is already there).
http://getfirebug.com/wiki/index.php/Extension_Migration#Firebug_1.10

Agree, but I think we can't completely avoid changes in the future
(sometimes we make a decision that turns out to be poor in the future).

It could block architecture and code improvements/evolution to not be able
to change the structure. Better to have a solution for keeping back
compatibility.

Could we somehow configure the loader to look for specified module at a new

I think we can do a lot with the right AMD loader

Honza

cutting down loader size from ~2000 to ~300 lines is already a big win.

maybe it will be better to just keep names in the file with rest of
the config (moduleConfig.js)
to avoid file API and keep things faster?

and xul version can work by just using CreateElementNS

not sure how much useful "packages" would be
but if this improves performance we definitely need it

It does support mapping a package into the global namespace but that is
not a workable solution for the problem I don't think as it will catch
all module paths with the same one-term prefix.

Instead of the "compat" directory we could just patch RequireJS to catch
certain paths and do the redirect internally as Harutyun suggested.

Right. Exactly.

The Sourcemint loader is that but most importantly it supports isolated
namespaces per package thus allowing complex dependency trees.

Correct; I consider Firebug one package at the moment. There are
basically two options to split things into packages:

   1) Create sub-packages within the firebug package to keep all sources
in the same repo.
       This could look something like this:
https://github.com/pinf/test-programs-js/tree/master/CanvasGraphics

   2) Put packages into their own repositories for independent
development. This makes most sense for packages that can be
independently developed and tested as well as used in other applications.

Option (2) would most easily be facilitated by a move to github where we
can have a github.com/firebug organization with various packages. It
could greatly improve the number of external contributions especially if
you can run a package from source within the released firebug (that is a
goal of the Sourcemint loader) without having to setup an extension dev
environment first.

How about targeting 2.0 and develop 2.0 on github with some common
packages and then some packages specfic to Firebug (chrome) and firebug
(lite). We could put Firebug up on github, patch it to use the souremint
loader and then refactor out various packages. Once we do this porting
of changes between 1.x and 2.x may become more manual. A better solution
may be to make the loader switch in 1.x as well but keep packages in
same source tree (vs separate repos). We can then import 2.x packages
into the 1.x source tree.

Any thoughts on this?

As soon as I have a solid day to do some prototyping. Should find some
time next week, two at the most.

Christoph

So, I did at R12809 (but, not much happy with that)

Honza

Related thread here:
https://groups.google.com/d/topic/requirejs/0TzfFQeLwhE/discussion

Honza