AJAX and FPCGI

[Fairlight]

>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.

> 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?

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.

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.

> 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.

> The fact remains that fpCGI and filePro both aren't designed to deal with
> almost any of the interfaces or standards created since the 80s properly
> (before you say it: the fp SQL & ODBC stuff is *useless* for app dev without
> writes!).  That I can 'trick' it at all makes me frankly grateful!  Any

fPCGI is barely "designed" at all.  What design there is, is seriously
flawed past the point of even considering it seriously for a production
system.

No argument from me on filePro not being designed to interface with
anything modern without headaches.  That's possibly the one thing you and I
will ever agree on.

> 'jail' is a huge thumbs up.  fpCGI was a real boon that way (tho I seriously
> doubt that's what the creators had in mind, as all the other products seem
> to be centered on keeping you locked into fp for developing your apps - much
> like Microsoft, they probably never really thought of it as an alternative
> application delivery infrastructure)

It was never intended to be an official product.  It was, from what I
gather, originally part of the Jumpstart or Gold development.  When that
was scrapped, someone convinced fP-Tech to release the CGI part of it
separately, and out came a very unsecured and unpolished fPCGI 1.0.

Its 2.0 version is only somewhat more secure, thanks to my efforts and
suggestions that were actually implemented.  It's still subject to
(tunable, but exploitable) race conditions that can eat your filePro
license alive, and if you use the backwards-compatible default methodology
with the command on the web page, it's almost as insecure as 1.0 in terms
of being able to attack a machine.  It's basically just slightly less
vulnerable.  It would require a complete rewrite to come even close to
being as secure as it should be.

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

mark->
-- 
"I'm not subtle. I'm not pretty, and I'll piss off a lot of people along
the way. But I'll get the job done" --Captain Matthew Gideon, "Crusade"