You can define the callback name in your options...

This is copied from: http://api.jquery.com/jQuery.ajax/

jsonpCallbackString

Specify the callback function name for a jsonp request. This value will be used instead of the random name automatically generated by jQuery. It is preferable to let jQuery generate a unique name as it'll make it easier to manage the requests and provide callbacks and error handling. You may want to specify the callback when you want to enable better browser caching of GET requests.

Matas, we can reopen. Can you provide some use cases? Examples or even a branch with this feature patched in?

this is my very rough initial proposal:

https://github.com/mataspetrikas/jquery/commit/52d806660183866840cc6b53343fa870851b48e6

we could probably do some url hashing making the callback naming potentialy shorter.

also it could be optional. what would be the most jquery-like way to pass this option then? somethign like this maybe:

https://github.com/mataspetrikas/jquery/commit/85416f01683e872da11e25ee7b09f0115092e0ae

I'm not sure about the code at line 269 though :/

anyway this change would make many public APIs happy, allowing them to cache the JSONP responses instead of going to db each time only because jQuery generated a random request string.

what do you think abou it?

Thanks Matas - glad you brought this to my attention to re-open, I think I missed the value the first time. I'm going to pull this into a local branch and play around. Also, cc'ing everyone else, hopefully they'll do the same.

The real issue here is when you have requests with the same callback name running concurrently (which is prone to happen).

I implemented the "constant callback" trick in jquery-jsonp: http://code.google.com/p/jquery-jsonp/ (and also added a pageCache option for reluctant services that simply never issue 304 responses for jsonp requests).

However, I refrained from adding it into the Ajax rewrite because of... drum roll... IE and also some fairly ugly $.browser checks all around.

Everything is explained on my blog for the curious: http://www.jaubourg.net/2010/07/loading-script-as-onclick-handler-of.html.

After having battled quite a lot, I came to reason and now think jQuery should have a viable and clean jsonp implementation while users with advanced needs can/should use a plugin.

I just want to add a note of support for a fix to this issue.

I'm using jsonpCallbackString just to gain browser caching of the cross-domain requests. The fact that using jsonpCallbackString means the success/failure/complete callbacks don't get called is causing me some pain. The jsonpCallbackString docs don't mention this 'feature'. If I could gain caching without using jsonpCallbackString I'd be delighted.

Matas' particular patch seems quite interesting and a relatively painless addition, I think we should consider it.

It's painless but completely wrong. If you have two concurrent jsonp requests with the same callback name, you cannot differentiate between the two of them (as I explained earlier): to handle concurrent requests you have to code an entirely different logic which involves a script tag injection technique that is entirely different to what is done in the script transport ( see jQuery-JSONP http://code.google.com/p/jquery-jsonp/source/browse/trunk/core/jquery.jsonp.js#171 ).

The technique used is described here: http://jaubourg.net/2010/07/loading-script-as-onclick-handler-of.html

Since the rewrite, setting the jsonpCallback option doesn't hinder the success/failure/complete callbacks (they are still fired). So it's safer to let application code decide when to use a fixed callback name and make sure there are no concurrent requests with a given callback name in the application logic.

We could introduce a jQuery-JSONP like solution (it's possible to feature-detect stuff -- dodgily but heh) but is the amount and duplication of code worth the effort, knowing setting the jsonpCallback option will do the trick anyway provided the application is careful about concurrent requests?

Ok, so based upon jaubourg's comment, I'm going to close this.