<div class="gmail_quote"><div><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Date: Thu, 21 May 2009 16:45:28 -0400<br>
From: Fairlight <<a href="mailto:fairlite@fairlite.com">fairlite@fairlite.com</a>><br>
Subject: Re: AJAX and FPCGI<br>
To: <a href="mailto:filepro-list@lists.celestial.com">filepro-list@lists.celestial.com</a><br>
Message-ID: <<a href="mailto:20090521164528.A13078@iglou.com">20090521164528.A13078@iglou.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
>From inside the gravity well of a singularity, Tyler shouted:<br>
><br>
> Well, the OP didn't say anything about what format he was using. Since it's<br>
> filePro it's not like it has native XML output only, no other choices<br>
> available. If he's needing to write the processing table regardless, he can<br>
> always choose to go JSON. Also, 10sec on google produced a javascript JSON<br>
> to XML conversion lib: <a href="http://goessner.net/download/prj/jsonxml/" target="_blank">http://goessner.net/download/prj/jsonxml/</a>. So still<br>
> not tragic.<br>
<br>
And for the majority of the community, AJAX isn't something they're going<br>
to be entrenched in, or have more than a cursory familiarity with. If they<br>
pick up a tutorial on it, the majority is probably going to fixate on XML,<br>
not JSON. <br></blockquote><div><br>Er....how much do you know about JSON and Javascript? JSON is just a subset of Javascript. Anyone who knows Javascript already knows JSON. A JSON is just a Javascript object literal.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> As for usage, what is your >75% guess based on? I've never seen any stats<br>
> that even hint at the proportion. Anyway, Google and Yahoo both offer their<br>
> web service APIs in JSON, so the proportion can't be insignificant.<br>
<br>
How do you draw a correlation of that type at all? Those are two houses<br>
out of how many tens to hundreds of thousands?</blockquote><div><br>Pretty easily. You've mistaken my point - I was trying to illlustrate that Google and Yahoo are big providers. So, if they are offering JSON APIs, there must be a significant proportion of service consumers wanting it in JSON format. Otherwise they wouldn't bother to support it, no? Even so, given the interpretation of those being two examples of JSON users they are still two of the biggest names on the web and therefore not bad indicators of JSON's popularity. <br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
There's standards-setters as well. From the wikipedia entry alone (I say<br>
"alone", since I don't always trust Wiki), it looks like while it has an<br>
RFC, it was one person's work. XML is a W3C standard. Until JSON gets the<br>
W3C's blessing, I think a lot would be hesitant to toss over one for the<br>
other--unless they're serious JS hackers.</blockquote><div><br>Um. ECMAscript (aka Javascript) is in fact a W3C standard, and JSON is a subset of ECMAscript. So... it *is* a W3C standard. As for being one person's work, what diff does that make?<br>
<br>JSONs are just another way to create objects in Javascript - hence the term object literals.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I note that the Wiki entry specifies that the MIME type is<br>
application/json. So when you send your responses, how are you getting<br>
it to be officially presented with the correct MIME type from fPCGI. The<br>
answer is--you can't. Even worse, you have -one- master error page in<br>
fPCGI, rather than one for every task. How do you specify specific errors<br>
in the return if something goes wrong? Answer: you can't.</blockquote><div><br>Yes, but who cares? I've never relied on fP or fpCGI to have any sort of reasonable error handling. And the correct MIME type only matters if you're using the browser to interpret fpCGI's output, which I don't. As for errors, I write my fP processing to transmit custom error messages if the processing itself encounters a problem (lookup fails, etc). If the standard fpFGI page comes back, my AJAX library emails me a full report and the variable just gets a 'false' assigned to the variable instead of an object. Pretty easy to test for and handle on the client side. Especially since I don't have anything mission critical on fP these days anyway - all been migrated to MySQL. Trusting a web app to fpCGI for something critical is madness, no doubt about it.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Personally I find JSON makes a lot more sense than XML if you have a choice<br>
> in export format. Much easier to work with on the client side, and MUCH<br>
> faster than XML. There are tons of blogs on the web extolling JSON over XML<br>
> for AJAX for these and other reasons.<br>
<br>
There are books out there extolling the virtues of Windows Server over<br>
Linux as well, but it'd be a cold day in hell before I actually bought into<br>
the hype and recommended that solution in a server environment when I had a<br>
choice. I -might- choose Windows Server over IRIX, but that'd be a damned<br>
close call.</blockquote><div><br>False analogy. There's no corporate marketing push for one over the other in XML vs JSON, so no hype a la MS vs Linux. And there is no grassroots movements 'hyping' one over the other that I know of either. And the things I mentioned - ease of use and speed - are both distinctly measurable, hence not hype.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
At least 2.0 got rid of the arbitrary command execution. Anyone on 1.0 is<br>
winging it on luck.</blockquote><div><br>Well, security by obfuscation has been a time honoured and venerable strategy for yonks now :D Seriously tho, how many hackers will have ever even heard of fpCGI, much less be able to recognize and exploit it? The rate of return for doing so would be so microscopic you might as well target systems using flatfiles for their data storage.<br>
<br>--<br>
Tyler Style<br>
<a href="http://malthusiansolutions.com/" target="_blank">http://malthusiansolutions.com</a><br></div></div><br>