Missing cleanup and custom callback in Jsonp

[Morik]

As i'm interested in using the jsonp API in a new plugin i had the problem that it's not possible (like using jquery) to specify a custom callback name. Additionally there is no cleanup after requests so that using a huge number of requests will blow up the source of the site. To understand why this is important to me: I want to regularly request a static jsonp file to check for new content. By doing this i don't want to use php to add a callback wrapper around it, so creating the jsonp file with a fixed callback would save much overhead.

[dtdesign]

I've changed the implementation to discard the callback function afterwards, this is the safest approach with automatic cleanup if you're passing in an anonymous function.

[Morik]

Well, the cleanup is done now, but without a custom callbackName the success function will never be called as it is not possible to specify it in a static jsonp file.there should be a way to specify one as option and in that case there shouldn't be a random one.

[dtdesign]

A static jsonp file doesn't make any sense to me, as it would cause the callback to be always invoked, regardless of any outer conditions.

[Morik]

The static jsonp file changes it's content from time to time and request only intend to load updates. So if i use a random query pararmeter (like a timestamp) in the url i can pull updates for many users in parallel without the php overhead a normal request would have. It's basically intendet as a update cache for nonsensitive (public) data, so most of the time no php is required. Jsonp is required as a normal json request is limited through same origin policy.

[dtdesign]

This sounds more like an ordinary HTTP request with HTTP 304 satisfies your needs?

[Morik]

The Data stored in the cache needs to be handeld and accessed by the plugins javascript, this was the reason i'll choose jsonp. Currently i'm using jquery for a simmilar problem and there is the option to specify a jsonpCallback and it works like expected and without any problems to have both: no problems with same origin policy and also the flexibility to use the returned data like any ordinary data from a default ajax call. I don't see how any other kind of request could give me the same benefit ?

[dtdesign]

I know exactly what jQuery offers, but I'm against implementing features just to reinvent the wheel.

There is already an established and perfectly supported standard for dealing with static files that change every once in a while. E-Tag and friends paired with HTTP 304 do the job just perfect and are designed exactly for what you're trying to do.

Please don't get me wrong: I know what you're trying to accomplish, and all I'm doing is pointing out the correct and less error-prone way of accomplishing the exact same using native APIs without reinventing the wheel.

[Morik]

Yes, using etag etc can save much more overhead, but to get updates without page refreshing i would still need to create a script tag, register a callback and cleanup after that which is exactly what your jsonp implementation is doing (and is the reason i'm using currently the jquery implementation). I automatically use etags if i didn't add a random query string to the file while loading it, but i would need to create nearly the same api already existing just to handle the static callbackname which seams a little bit strange to me.

[dtdesign]

You're using jsonp to replicate native HTTP features!

A simple, periodic AJAX request with a properly configured webserver (needs to output etags/last-modified for cacheable content) is enough and provides the same data in a sane way to any application trying to interact with it.

http://stackoverflow.com/a/12501696 provides a brief explanation of how 304 works and how browser handle it in combination with XHR.

[Morik]

I'm using jsonp to be able to perform cross domain requests. It's simple, using multiple (sub-) domains like on woltlab makes it difficult to handle static files on one sub-domain by all others. As far as i know this was exactly the reason why jsonp was developed in the first place: to overcome the cross-domain restrictions.