On 3/14/07, David Huynh <[EMAIL PROTECTED]> wrote:
> Johan Sundström wrote:
> > On 3/13/07, Johan Sundström <[EMAIL PROTECTED]> wrote:
> >>> [...] &mime-type=output-mime-type [...]
> >>>
> >>> [...]
> >>>
> >>> output-mime-type can be anything you want. It is entirely optional.
> >>>
> >> That doesn't quite seem to work; misdocumented? I fail to override the
> >> application/json(p) output of writers exhibit-json(p):
> >
> > I later found out it was just misdocumented (should read "mimetype").
> > I fixed the wiki docs.
> >
> > I would still like upstreams help to cater the JSONP &callback=
> > argument, though.
>
> The reason for out-callback is because I would like the architecture to
> support custom parameters for both readers and writers. Readers'
> parameters start with in- and writers' with out-. Do you think it's
> worth breaking this pattern?
I see no particular point in disallowing people to use that pattern if
it helps them, but I do think the JSONP convention should work too.
So: +1 on making &callback= work and -0 on making &out-callback= stop
working. There is no technical reason why both could not be legal.
(Given both in a single request, I'd prefer &callback= to take
precedence, or perhaps the output "if(typeof
Babel=='undefined')Babel={};callback(Babel.data={/*json*/});out-callback(Babel.data)"
if you'd like to be really resilient.)
My point is that it's easier to consume data and requires less
understanding of all the technicalities to write (Exhibit 2.0
example):
<link rel="exhibit/data" type="application/jsonp"
href="http://simile.mit.edu/babel/translator?reader=...&writer=exhibit-jsonp&url=...";
/>
than to write:
<link rel="exhibit/data" type="application/jsonp"
href="http://simile.mit.edu/babel/translator?reader=...&writer=exhibit-jsonp&url=...&out-callback=";
/>
which would be required with the current setup, and suddenly requires
out-callback to be present, be the last parameter, and have the empty
value. People are likely to get either property wrong, and I find no
appetizing reason for that. It's also typing I'd prefer not to have to
do and a property of the API I'd like to be able to forget about, as
following JSONP convention for JSONP APIs, when there is one, makes
lots of sense.
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
