<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Hi Stephan, Mike and all!</div><div> </div><div>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:</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div>How do you feel about cross-domain requests? If you don&#39;t mind other web services utilizing your infrastructure for these requests, you could setup CORS (<a href="http://enable-cors.org/" target="_blank">http://enable-cors.org/</a>). 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&#39;d be happy to assist.</div></div></div></blockquote><div><br></div><div>My understanding is that, currently, my code would have to be hosted off <a href="http://delph-in.net">delph-in.net</a> 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 &#39;jsonp&#39; 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 &#39;callback&#39; parameter. Sounds like Mike has more of a handle on it than I though :)</div><div><br></div><div>Cheers,</div><div>Ned</div><div><br></div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span class=""><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">  i think i<br>
will standardize on 3.3 and upwards then, and if and when you get to<br>
adding a client interface to pyDelphin, i will let you find out<br>
whether and how to work around Unicode limitations in 2.x :-).<br></blockquote><div> </div></span><div>Ok. Last night I put together a MRS-JSON serializer-deserializer, based on our discussions. So that part is ready.</div><div><br></div><div>Regarding unicode: I don&#39;t think I have experienced the problem you&#39;re describing, but in transport the requests should be encoded byte sequences, whether it&#39;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&#39;t implicitly decode bytes, so you might see more errors initially, but in the end it is (I think) more understandable.</div><div><br></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><a href="http://nedned.net" target="_blank">nedned.net</a></div>
</div></div>