OpenUru.org

Thank you very much!
Unfortunately it doesn't work yet.
I didn't mention it because I wasn't sure whether if was going to work or not, but the Google Analytics Tool interferes with the final output, so it doesn't get recognised as valid JSONP.
Also would it be possible for you to send out an HTTP header for declaring the content type of the document? There are two solutions for solving the problem:
Solution 1
Simply take out Google Analytics when type=jsonp

Solution 2
Since JSONP is actually javascript, you could simply avoid printing the <script></script> tags and just leave the google analytics code there, it will be executed with the JSONP code with no problems.

Actually, I thought I had taken the Google Analytics out (that's what happens when you change your mind about the name of a variable part way through coding)... and I remember you did ask about the header, but I forgot .

OK v1.02 coming up...
Before I get JW to push it to the live server, can you check that you're getting the right response from my test instance on this URL (use you own function name, obviously): If that's what you're expecting then I'll commit it. Thanks.

I'll just push this little red button. What could possibly go wrong?

It's live.

eheh
Ok, Now your code seems perfect, it is read as JSONP and it gets executed on the client browser. There is one error though that is not really generated by you: the welcome message to Uru has a new line character, javascript doesn't seem to like it.
You could parse the welcome message with the php function nl2br() to turn all the new lines to "<br />" or you could add a "\" before the new line character to properly escape it in javascript.
Just to be sure: also pass it thru the htmlentities function to turn all the double quotes (") into their respective HTML entities ("); because if Cyan starts using double quotes in their welcome message it will break the JSON syntax XD

Thanks for the feedback, Leo! It'll probably be Wednesday before I get a real chance to do another update, as RL work will need attention.

nl2br() - If I recall, that function simply inserts the <br /> before any existing newline character(s) rather than replacing them, so wouldn't that still leave the same problem in the resultant string?
Is the javascript insistent on the XHTML <br /> or is it happy with the HTML <br>? - I assume the latter.

htmlentities() - Yes, that's probably a good idea, and something I ought to do for other parts of the script. I assume single quotes are OK, so using the ENT_COMPAT flag should be enough.
Is using the UTF-8 character set during conversion OK, or is it better to stick to Latin1?

These string fixups are probably something that I can do during the caching of the data I fetch from the Cyan server, rather than on every request.

Question, Leo... Where are you finding that new line character? I'm not seeing it in the message I'm pulling from the Cyan servers, and I don't believe my code is adding one anywhere (except at the very end of the JSONP output after the paretheses close), so I'm a bit confused .

nl2br() - If I recall, that function simply inserts the <br /> before any existing newline character(s) rather than replacing them, so wouldn't that still leave the same problem in the resultant string?

yeah, probably it works that way. I'm sorry I misinterpreted the name of the function "new line to br".

Is the javascript insistent on the XHTML <br /> or is it happy with the HTML <br>? - I assume the latter.

You can use the latter it should be no problem

Is using the UTF-8 character set during conversion OK, or is it better to stick to Latin1?

UTF-8 is perfect, usually ajax requests always use UTF-8 encoding.

Where are you finding that new line character?

Actually....it's strange. When I tried the script yesterday it was reporting a new line between "Welcome to Myst Online: Uru Live!" and "Bug Chucker now available...". But today the new line is no longer there and the script works

Leonardo wrote:

Where are you finding that new line character?

Actually....it's strange. When I tried the script yesterday it was reporting a new line between "Welcome to Myst Online: Uru Live!" and "Bug Chucker now available...". But today the new line is no longer there and the script works

Actually that's fair; you were probably seeing an old, saved version of the status message that I've since overwritten with a different one, so it's quite possible that there was a newline in there, so it's reasonable to assume that one might reappear in the future. I'm also trying to think ahead to the possibility that Cyan might start to use a second line to report the CAVCON status.

Yeah, the nl2br() function name is maybe a bit misleading, but I guess it works the way it does to avoid breaking the layout of the resultant HTML/XHTML source. But stripping out or escaping any \n or \r characters should be quite simple.

OK, I blew out the RL paperwork job I should have been doing to make the changes that Leonardo suggested. Just needs a server push from JW now

I will follow your own good example and sense of priorities.

Done.