On Tue, Jul 23, 2013 at 5:59 PM, Jakob Heuser <ja...@felocity.com
> In the spec, we have exactly one global keyword "define" that must exist to
> comply with AMD (Global Variables). If config() moves to specification from
> draft, would we also ask that people implementing config implement it as
I do not think we need to standardize on an entry point name -- those
are easy enough to feature detect for, where the actual config
properties might be harder to do that way. If we do specify the
loader-specific function entry point, I can see it just being "look
for a .config() function off the loader's main global. If the loader
implements a global require, it can be found at `require.config`".
I think it is important to put on the loader API and not on define(),
which is the declarative module registration, and many modules can be
shared without knowledge of a specific loader API.
> I would be comfortable with moving "paths" and "shim" out of draft. "paths"
> is really straightforward config, and "shim" is something that as people try
> and adopt AMD they would appreciate having a consistent interface for.
I would also vote for module config and map, as they have been useful
in practice. In fact, I would rather see module config and map be
standard than shim, as shim is really a crutch for old code where
module config and map are both useful in a pure module environment.
So, I am happy to standardize shim, but I think a loader implementer
can make a credible case for not implementing it.
For any of the config properties that we standardize (move them out of
draft status), I still think it is fine to say they are still
optionally implemented. If they are implemented in a loader (and I
think the loader would have better success if they are), then the
implementations must conform to the API doc.
But it would be good to hear others thoughts on a workable set to take
out of the draft category.