> Okay, we really need to resolve this and land something; we're already behind schedule.

I didn't know this was a blocker. When did this happen?

> Regardless of the whether the entry point is in ajax or manipulation, we have to expose and document an entry point here.

Question: where will this be documented? In the ajax module doc or the manipulation module doc? Elsewhere?

> I am not sure how an overridable hook is better for alternate ajax impls since they'll need to now punch in the hook. Plus, the stub will be left in manipulation.js. To me it just doesn't make sense to leave a reference to $.ajax inside manipulation and make code punch it out.

I fail to see how "punching in a hook" is worse that incanting a method out of thin air. If some functionality has to be provided to the manipulation module for it to properly function, how does it make sense to define the hook in another module?

You're stating what I'm proposing (keeping the stub in manipulation.js) then you say it doesn't make sense to you to leave a reference to $.ajax inside manipulation. Why?

How is a reference to `getScriptSync` buried inside `domManip` "better" than a reference to `ajax` inside a 5-line long `_execScriptFromSrcHook`? Don't you think the former will give the impression you have to have the default ajax implementation in order for domManip to function? BTW, how is `domManip` relevant to someone implementing (or bridging with) another ajax implementation? Isn't a short method called `_execScriptFromSrcHook` with a simple call to `ajax` inside that much clearer than a `getScriptSync` that is nowhere to be found in the code?

You made it clear what you think is better but could you lay out the actual rationale behind it? I know you'd prefer this to be in the default ajax implementation but I still don't know why. How is this method **belonging** to the ajax module?

> The method here is doing what it says on the tin, it's running scripts synchronously. The choice to avoid global events also makes sense, there is no asynchrony.

This method:
* is inconsistent with other helpers (no callback parameter)
* doesn't actually make a script request but a plain text one
* will bypass script prefilters and handle default cache value improperly
* disables global events with no other reasons than `domManip` needing to silence global events. Events can be triggered synchronously.

Also, as used in `domManip`, it will fail silently in case the request is cross-domain and the target server doesn't support the origin of the page.

None of this is advertised on the tin. The method is worthless as an ajax helper because it is **not** an ajax helper.

> So although it has limited utility

It is far more than limited, it is unique to `domManip`. What other usage do you have in mind for this method outside of `domManip`?

> and we wouldn't advise end-users to avail themselves of it,

Good luck with that. This, btw, is going against everything we've been trying to do lately regarding exposing API. If we expose the method on the ajax module, we'll have to document it there and people will use it. 3 versions down the line, we'll be debating whether or not we should make it more generic (it's not like it never happened before).

If we put it in the manipulation module and call it `_execScriptFromSrcHook` then end-users will have a harder time justifying using it for doing synchronous ajax requests and we won't have to debate how generic it should be in the future.

> an ajax implementor needs to provide code for this case.

Someone using another ajax implementation (or the ajax implementation of another library) must be made aware of this. Hence the necessity of the presence of the hook in builds without the default ajax implementation.

What are the reasons that make you think the intent of this method is made clearer by defining it in the very module that will not be part of builds where said method needs to be provided?

I'm sincerely lost here: what are the actual arguments for putting this in the default ajax module?