Re: [amd-implement] Digest for amd-implement@googlegroups.com - 1 Message in 1 Topic

[Jakob Heuser]

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 define.config()?

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.

--Jakob

On Tue, Jul 23, 2013 at 5:27 PM, <amd-im...@googlegroups.com> wrote:

  Today's Topic Summary

Group: http://groups.google.com/group/amd-implement/topics

• Common configuration draft [1 Update]

 Common configuration draft

James Burke <jrb...@gmail.com> Jul 23 03:56PM -0700  

Looking at amdjs-tests, it looks like these loaders support the
following config:
 
inject:
"paths"
 
requirejs & zazl:
"map"
"module"
"packages"
"paths"
"shim"
 
curl and dojo are not in the test suite so I cannot speak to them.
 
"map" config came from a dojo concept, but it was a bit different, not
sure if it is supported as "map" as mentioned in that draft in dojo.
 
I'm open to marking some of those config options as non-draft, but
feel the other implementers need to agree, and in particular, we would
have them in the tests and passing them before moving them out of
draft.
 
James
 
 


 

--
You received this message because you are subscribed to the Google Groups "amd-implement" group.
To unsubscribe from this group and stop receiving emails from it, send an email to amd-implemen...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[James Burke]

On Tue, Jul 23, 2013 at 5:59 PM, Jakob Heuser <ja...@felocity.com> wrote:
> 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
> define.config()?

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.

James