JSON without AJAX

[VK]

Mission statement:

A mechanics to get text stream into browser from any Web location
without reloading the current page.

1) This mechanics has to support *at the very least* IE 5.5 and higher
and Firefox 1.5 and higher: but it may be completely different from one
browser to another. It is important only to be able to build an
uniformed interface atop of it.

2) This mechanics has to exploit some core features of modern browsers
so it would not be possible to lock it without stopping the browser to
be a browser (like visited links sniffing).

Com'on guys: let's hack sh** out of them! :-)

My initial donation:
1)
<link
id = "JSON"
title="JSON"
rel="alternate appendix"
type="text/plain"
href="data.txt"
charset="iso-8859-1"
hreflang="en-US">

Not even a hack, but seems to way to get the data.txt content

2)
<link
id = "JSON"
title="JSON"
rel="alternate stylesheet"
type="text/css"
href="data.css"
charset="iso-8859-1"
hreflang="en-US">

That would be nearly ideal as style rule declaration is almost
identical to JSON object syntaxes. But unknown attributes are ignored
so:
..data {
key1:value1;
key2:value2;
key3:value3;
}
will result into empty parenthesis
..data {}

Any way to stop it?

3)
IE-only "download" behavior
Not explored plus seems too easy to "upgrade security" if Microsoft
decides to. Still decided to mention.
P.S. If you find some really breathtaking solution conformant to the
requirement 2) above you may want to try to copyright it first before
posting in a public forum. Or you may don't - but needs to be
mentioned.

[Matt Silberstein]

On Thu, 22 Dec 2005 22:50:33 -0500, in comp.lang.javascript , Randy
Webb <Hi************@aol.com> in <cI********************@comcast.com>
wrote:

Thomas 'PointedHead' Lahn babbled the following incoherently in
comp.lang.javascript:

Randy Webb wrote:

Thomas 'PointedEars' Lahn said the following on 12/22/2005 2:32 PM:
That said, "loading scripts" after the document was loaded is still
unreliable.
No more unreliable than trying to load them when the page is loading. Nonsense.

I can load .js files dynamically just as reliably as I can load them
statically. Either something is reliable and always works, or, it is
unreliable and doesn't always work. Since external files can never
"always be loaded" then it is unreliable. As is loading them
dynamically. That makes them both unreliable. And unreliable is not
relative. If two things are both unreliable, then they are equally
unreliable.

Nonsense. Something can work 99% of the time, something else 1%, they
are not equally reliable.
In the future, it might help you if you would endeavor to understand the
language I am using and the meanings of what I post. It would keep you
from replying as much and keep me from correcting you so much.

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"

[VK]

Matt Silberstein wrote:

Nonsense. Something can work 99% of the time, something else 1%, they
are not equally reliable.

That is a persistent discussion in this group of the definition "work",
"doesn't work", "universal" and "reliable". Like:
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/c532483403801387/13291deab867e19b>

As both sides seem to have explored all possible arguments and
injurations, one can just join to one side or other.

JavaScript/JScript program just cannot "work" in all possible
environments - in the meaning always produce the exact intended results
- unless it's something really primitive on JavaScript 1.0 level.

But the program should always try to handle its environmental problems
internally thus never let any errors to go uncaught out of the program
context - so it would halt any script execution on the current page
(JavaScript "blue screen" equivalent).
I say "should try to handle" instead of "must handle" because there are
always situations which are out of scope and power of software
developers (think Konqueror 1.x)

Also in a functional environment program should show a stable
functionning *withing the spelled usage rules*.

Therefore I don't care at all if say script impants will not work under
Netscape 4, Opera 6, SuperMuper 0.1 etc. - as long as attempt to use
them do not lead to the script abort and as long as user gets a nice
explanation in say myObject.error.message field.

I also don't care if it will be defined that script implants shouldn't
be used no more than say 1024 per page with the max refresh rate say
5sec - as long as it stated clearly in the manual.

But as long as the defined system requirements and usage rules are
accomplished, the script has to work as intended.

That's the point of view I follow and will follow. For a discussion of
how wrong I am (if any - and w/o my participation) it would be the most
approipriate to move the relevant discussion into a new thread.

[bwucke]

VK wrote:

Matt Silberstein wrote:
But the program should always try to handle its environmental problems
internally thus never let any errors to go uncaught out of the program
context - so it would halt any script execution on the current page
(JavaScript "blue screen" equivalent).
I say "should try to handle" instead of "must handle" because there are
always situations which are out of scope and power of software
developers (think Konqueror 1.x)
or out of their concern. If I write a greasemonkey (Firefox extension)
script, do I really have to worry if it works correctly in MSIE and
Opera? Do I have to check for methods I -know- Firefox supports, and
know the script won't be ever executed outside Greasemonkey sandbox?

Right now I'm writing a js app where I don't bother about MSIE
compatiblity. It does one simple check, and says "Sorry, MSIE is not
supported." It makes heavy use of features MSIE doesn't support, and
trying to be compatibile would severely cripple it. I know the target
audience has almost entirely switched to non-MSIE browsers, so I don't
worry too much about it. And for all the rest there's a primitive
non-js text-only interface. Sure I could try making workarounds and
crippled versions of all its parts to get it to run in MSIE, but that
would possibly double my amount of work, and I had enough headaches
with Opera support already.

Also in a functional environment program should show a stable
functionning *withing the spelled usage rules*.

You can't spell out -all- the rules. Try spelling out the rules for
hardware: non-faulty, non-infected, non-crippled, non-overloaded,
non-underpowered, non-overheated...
You didn't say the PC running your app can't be submerged 5m deep in a
swamp, therefore your app failing to run on it is not reliable?
We should draw a clear line of responsiblity. An app running on a
faulty system isn't necessarily wrong. It's the system that's wrong.
And with the state of JS interpreters nowadays, ALL systems are more or
less faulty. Apps may do all within their power to patch and avoid
holes in the system they are running on, but avoiding -all- of them is
pretty much impossible.
If you disagree, please port some bigger JS app to Links javascript
engine first.

[Lasse Reichstein Nielsen]

"bw****@gmail.com" <bw****@gmail.com> writes:

If I write a greasemonkey (Firefox extension)
script, do I really have to worry if it works correctly in MSIE and
Opera? Do I have to check for methods I -know- Firefox supports, and
know the script won't be ever executed outside Greasemonkey sandbox?

Since Opera has introduced user.js-scripts that are compatible with
greasemonkey, then it would be nice if you check that it works there
too :)
<URL:http://www.opera.com/support/tutorials/userjs/examples/>

But no, if you write for a specific platform, then obviously you need
only consider the variations inside that platform.
When nothing else is stated, in this group the default assumed
platform is the web in general, where you cannot safely make any
assumptions.

You make life much easier for yourself using standards, since they
are more likely to be supported on other platforms as well, should
you ever want to extend the scope to cover another platform - and
you only need to learn how to do things one way :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'

[bwucke]

Lasse Reichstein Nielsen wrote:

"bw****@gmail.com" <bw****@gmail.com> writes:

You make life much easier for yourself using standards, since they
are more likely to be supported on other platforms as well, should
you ever want to extend the scope to cover another platform - and
you only need to learn how to do things one way :)

Well, I do. Primarily because standards are best documented
(self-documenting) so they are easiest way to write. But then, when I
have my nice and pretty standards-compilant source, first, it doesn't
work in any real browser (except of Amaya maybe ;) and second, it lacks
a few features that aren't part of any standard but are quite handy and
widely supported. So I start breaking my nice standard-compilant code
to make it work... Pity, but that's the state of things.