OT: xml vs json (was AJAX and FPCGI)

Tyler tyler.style at gmail.com
Thu May 21 14:20:12 PDT 2009


> Date: Thu, 21 May 2009 16:45:28 -0400
> From: Fairlight <fairlite at fairlite.com>
> Subject: Re: AJAX and FPCGI
> To: filepro-list at lists.celestial.com
> Message-ID: <20090521164528.A13078 at iglou.com>
> Content-Type: text/plain; charset=us-ascii
>
> >From inside the gravity well of a singularity, Tyler shouted:
> >
> > Well, the OP didn't say anything about what format he was using.  Since
> it's
> > filePro it's not like it has native XML output only, no other choices
> > available.  If he's needing to write the processing table regardless, he
> can
> > always choose to go JSON.  Also, 10sec on google produced a javascript
> JSON
> > to XML conversion lib:  http://goessner.net/download/prj/jsonxml/.  So
> still
> > not tragic.
>
> And for the majority of the community, AJAX isn't something they're going
> to be entrenched in, or have more than a cursory familiarity with.  If they
> pick up a tutorial on it, the majority is probably going to fixate on XML,
> not JSON.
>

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.


> > As for usage, what is your >75% guess based on?  I've never seen any
> stats
> > that even hint at the proportion.  Anyway, Google and Yahoo both offer
> their
> > web service APIs in JSON, so the proportion can't be insignificant.
>
> How do you draw a correlation of that type at all?  Those are two houses
> out of how many tens to hundreds of thousands?


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.


> There's standards-setters as well.  From the wikipedia entry alone (I say
> "alone", since I don't always trust Wiki), it looks like while it has an
> RFC, it was one person's work.  XML is a W3C standard.  Until JSON gets the
> W3C's blessing, I think a lot would be hesitant to toss over one for the
> other--unless they're serious JS hackers.


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?

JSONs are just another way to create objects in Javascript - hence the term
object literals.


> I note that the Wiki entry specifies that the MIME type is
> application/json.  So when you send your responses, how are you getting
> it to be officially presented with the correct MIME type from fPCGI.  The
> answer is--you can't.  Even worse, you have -one- master error page in
> fPCGI, rather than one for every task.  How do you specify specific errors
> in the return if something goes wrong?  Answer:  you can't.


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.


> > Personally I find JSON makes a lot more sense than XML if you have a
> choice
> > in export format.  Much easier to work with on the client side, and MUCH
> > faster than XML.  There are tons of blogs on the web extolling JSON over
> XML
> > for AJAX for these and other reasons.
>
> There are books out there extolling the virtues of Windows Server over
> Linux as well, but it'd be a cold day in hell before I actually bought into
> the hype and recommended that solution in a server environment when I had a
> choice.  I -might- choose Windows Server over IRIX, but that'd be a damned
> close call.


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.


> At least 2.0 got rid of the arbitrary command execution.  Anyone on 1.0 is
> winging it on luck.


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.

--
Tyler Style
http://malthusiansolutions.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20090521/47da5fba/attachment.html 


More information about the Filepro-list mailing list