Re: [json] Re: Waiting on browsers?
- Hey Lloyd,
Thanks for the link. I was not aware of BrowserPlus from yahoo. I'm
curious as to what grab bag of tricks they used to pull this off.
Time to begin spelunking...
On Sun, Jun 1, 2008 at 11:24 AM, lhilaiel <lloydh@...> wrote:
> A proof of concept of #1.
> --- In firstname.lastname@example.org, "cisco_sethcall" <sethcall@...> wrote:
>> I'm the type of person that is pretty impatient, and given the past
>> history of browsers with regards to adopting standards, I'm curious on
>> anyone's feelings on implementing JSONRequest before the browser's
>> officially do (obviously FF has a plugin but it's gotta be in IE at a
>> miminum before anyone seriously begins to adopt--also I'd say Safari
>> and then Opera would be pretty important overall).
>> I tend to think that we should just keep pushing the envelope and not
>> wait on browsers--I mean, after all, AJAX is just a ton of hacks and
>> workarounds pushing the current envelope to it's limit, and look what
>> interest it's created. And like with XMLHTTPRequest, it got used
>> first and then became a standard... why not with JSON?
>> In my mind, there are really three ways to do it:
>> 1) Build and maintain plugin for every major browser.
>> 2) Build JSON on top of Flash flash.net.socket
>> 3) Build JSON on top of Java Applet
>> And pro/cons of each:
>> * Pro: No requirement on another technology
>> * Con: Installation process must be extremely painless. Failure to do
>> so is failure for widespread adoption. (Ask applets about this)
>> * Con: Personally not sure if every browser offers a plugin model deep
>> enough to implement JSON.
>> * Con: Have to build & maintain multiple plugins for wildly different
>> plugin models.
>> * Pro: Flash is most ubiquitous of plugins
>> * Pro: Build on
>> * Pro: No security prompt for cross-domain requests. (instead policy
>> file at root of origin domain indicates which other domains are
>> * Con: flash.net.socket does not support SSL (no indication if or when
>> that I can see), but one could build HTTP transport with it
>> * Con: XmlHTTPRequest within Flash uses same mechanism of browser,
>> which bothers me a bit because of max of 2 concurrent requests per
>> domain by default in IE/FF. I assume one can't control cookies or all
>> headers as well with XHR either so that's a problem.
>> * Pro: Java Applet is extremely capable as a development
>> environment--most powerful/most flexible.
>> * Con: Cross-domain requests required signed jar which require use to
>> click YES when the applet loads to security prompt.
>> * Con: not as widely adopted compared to Flash
>> bridge from the context of the flash player or applet.
>> Anyway, does any one have strong feelings about any of these 3
>> approaches, has a different idea, or thinks we should just wait for