First off: despite the arguing all technical aspects below, I'm
somewhat pro suggesting the use of jsonp over json by default. The
upshot is that it makes it easier to cross site boundaries, and the
down side is that it (I argue) would mean that users need to give each
data set('s callback) unique names (which are legal javascript
identifiers, and do not clobber any javascript variable they use). The
perhaps most likely names ("exhibit" and "Exhibit") also have rather
catastrophic effects. :-)
On 5/4/07, David Karger <[EMAIL PROTECTED]> wrote:
> I wonder if it is worth "standardizing" around the jsonp callback so
> that people don't have to fiddle with files as exhibits move from site
> to site.
It might be, though it does sacrifice interoperability with some other
tools and environments. It also breaks the web security model (which
only allows pages from the same site to read and act on the data), but
it could be argued that that is indeed our primary cause so the point
is moot.
There has been some commotion on the web about security (the data
leakage perspective) and jsonp for this reason for this potential
situation:
* example corp has an intranet at example.com, possibly even with some
login mechanism
* example corp has sensitive data published on this site at
/fix/location.js in jsonp format
* evil corp (at evil.com) references example.com/fix/location.js
(known url, unknown data attack)
* example corp employees (whose browser session is presently logged in
at example.com) visiting evil.com lets evil corp can steal the present
contents of example.com/fix/location.js
This is not the case with json data, and if we do standardize on
suggesting jsonp be used by default, it is at least facts we should
ensure that exhibit authors are aware of.
That said, the data leakage aspect is probably not much of a concern
for most people, but to a greater extent, the bandwidth sharing might
be, as external pages referencing data from your own site might cause
traffic you can't afford (same problem as hotlinked movies, images or
script code).
I personally don't mind either case, but feel that the relevant facts
should be presented for others who might want to be part of making an
informed decision (for themselves, if perhaps not for the Exhibit
project).
> ie, to require that _every_ exhibit file use the foo() convention. If it
> is local and we care, then exhibit can strip the foo() wrapper and
> parse the file itself, instead of invoking. Could also use a standard
> function name so there is no need to add the jsonp-callback
> attribute either.
If we do so, I think we should also call it application/exhibit-jsonp
rather than application/jsonp, or we will dilute the jsonp standard
into something less useful.
A default callback name (vs jsonp's dynamic one, picked by the page
referencing the data) also (pessimistically) only lets you include a
single exhibit jsonp file per page while maintaining a recollection of
the origin of each item loaded, since the shared callback would not
know from which url each data set arrived. This degrades
interoperability and remixability of the data.
Ideally, a callback name should be unique to every jsonp file to avoid
that issue, similar to a guid but, needing to be a valid javascript
identifier, might rather look like "x496baa12d1e524ca44ca9ab22bd249ca"
-- first character alphabetic, no { - } characters.
Regarding load order, it might (optimistically) in practice be shown
to be presently be serialized (and not asynchronic) by all browsers,
but to the best of my knowledge, there is no HTML nor DOM standard
that gives any such guarantees, unless we force the data to be marked
up like this, instead of using the nice <link> tags:
<script type="text/javascript"
src="http://simile.mit.edu/.../exhibit-api.js";></script>
<script type="text/javascript" rel="application/exhibit-jsonp"
src="http://site1/data1.js";></script>
<script type="text/javascript" rel="application/exhibit-jsonp"
src="http://site2/data2.js";></script>
That would both force the above order of the script tags (Exhibit API
first, exhibit jsonp data afterward, in any order), and it would also
make it harder to have multiple exhibits on the same page.
If we still do standardize a default callback name picked when one
isn't given, I would suggest "Exhibit.data".
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
