[developers] RESTful ERG parsing

[Ned Letcher]

Hi Stephan, Mike and all!

In accordance with my previous excitement about an ERG parsing API, I sat
down to try to write some javascript to consume the API but forgot about
the cross domain limitation that Mike mentioned:

How do you feel about cross-domain requests? If you don't mind other web
> services utilizing your infrastructure for these requests, you could setup
> CORS (http://enable-cors.org/). Alternatively you can use JSONP (not to
> be confused with JSPON I mentioned earlier), where you wrap the json object
> in a client-defined function callback. Of these options, JSONP is the
> easiest to setup, and I'd be happy to assist.
>

My understanding is that, currently, my code would have to be hosted off
delph-in.net in order for it to make a successful ajax request to the API.
It sounds like your intention Stephan was for this resource to be consumed
by all manner of clients, so I would like to add my endorsement for this
enhancement. Looking into it briefly, I think Mike is right, in that adding
JSONP support would be is as simple as adding a new 'jsonp' output target,
and then wrapping the JSON object to return for this output in a function
call whose name is the value of the user supplied 'callback' parameter.
Sounds like Mike has more of a handle on it than I though :)

Cheers,
Ned





>
>
>>   i think i
>> will standardize on 3.3 and upwards then, and if and when you get to
>> adding a client interface to pyDelphin, i will let you find out
>> whether and how to work around Unicode limitations in 2.x :-).
>>
>
> Ok. Last night I put together a MRS-JSON serializer-deserializer, based on
> our discussions. So that part is ready.
>
> Regarding unicode: I don't think I have experienced the problem you're
> describing, but in transport the requests should be encoded byte sequences,
> whether it's Python 2 or 3. Python 2 often confuses byte strings and
> unicode (codepoint) strings and operations using both will implicitly
> up-cast bytes (assuming some default encoding) to unicode. Python 3 makes
> the division more clear and doesn't implicitly decode bytes, so you might
> see more errors initially, but in the end it is (I think) more
> understandable.
>
>


-- 
nedned.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.delph-in.net/archives/developers/attachments/20160419/9ae499b9/attachment.html>