JSON without AJAX

[VK]

Addon to the previous post <Message-ID:
<[email protected]>

That should be clear that this is not the question of *inventing*
standards. The posed questions are connected to the core browser
functionality, therefore each existing browser with script support
already has some standard implemented in its source code - with all
if-else branches and priority flags. Just no one throught up-to-date
necessary to share it with the public. So it needs to be done by the
public themselves.
IMHO

 

[bwucke]

VK napisal(a):

"Reliable" means it works under _all_ circumstances.

Then let's define exactly what "reliable" would mean in this case and
what circumstances should be expected.

(pseudo-code)

Variant 1 - hardcoded kill
[remove existing node] scriptObject
[add new node] scriptObject
[assign] scriptObject.src = newURL

Does removing the node devalidate the current script context of
scriptObject - so it would be free for garbage collection?
What moment such devalidation occurs (if it does) - immediately upon
removing the node? somewhere later?

I'd say, never recycle deleted object (explicitly, at least. Just let
the browser and OS handle all recycling.). Assign an unique identifier
to each imported script, so even loading the same script twice won't
result in overwriting one instance by the other. Never reuse discarded
script object. This way you don't have to worry about it anymore. You
dump it in the garbage can and don't worry if garbagemen arrive in a
moment or tomorrow, it's not of your concern. And if never, then we
have a mild memory leak. Let's first handle script loading and fix the
leak (if any) later (say, by traversing the tree of the loaded script
and deleting each leaf separately, if we have to.)

What moment we can try to access new scriptObject? When the
text/javascript input stream is closed?

a bet that looks safe is what is located on the bottom of the script
gets loaded last. Just add setting a marker variable to the bottom of
the file and poll it, or even trigger an event, or just launch a
predefined 'perma-script' function by a toplevel call on the bottom of
the loaded file.

--perma-script--
function loadScript(newURL)
{
[set and export new seed/mark/identifier/whatever.]
[create node]
[assign] scriptObject.src = newURL
return;
}
// now the script is loading.
function onAfterScriptLoad()
{
//now we assume the script is loaded.

}

--loadable-script--
//...
// lots of stuff here, whatever we want loaded.
//...

loaderscript.onAfterScriptLoad();
--end-of-file--

I think a pretty secure metod of caging the loaded scripts would be
loading them into dynamically created hidden iframe subdocuments.

When interpreter finished some
tuneup job somether after? Or even while text/javascript input stream
is still open?

even if it is, everything we needed is already parsed and loaded.

If newURL doesn't exists or is not reachable: do we have any formal
signs to see the trouble?

We never get the "I'm alive" reply from the child script. We could set
a timeout to try surviving that. Worse problem if the script is
corrupted (but since we likely have access to it as literal string, we
should be able to check some hash if we want to... and if we survive
the parser error.)

Variant 2 - soft replacement
Same questions but getting even more tricky.
I doubt very much that there are any written standards for it - but I
can be crossly mistaken.

I'm not even sure if/how legal is it.
Assume script changes its own src, then continues running. A live,
active, currently running function gets deleted/garbage-collected?

 

[bwucke]

Robert napisal(a):

A has a 10% chance of failing, and B has a 90% chance of failing.
A and B are equally unreliable??

I think Randy meant - "almost". 10% is so huge unreliablity that
between it and 90% the difference is marginal. Would you pick an
airplane that falls in 90% cases or one that falls in 10% cases - or
would you rather go by bus, facing such a choice? And what is "reliable
enough"? 1%? 0.01%? There's little sense in pondering that. Either
something is completely reliable (that is, given -all- the
prerequisites it demands, it will -never- fail), or we still use it IF
we can recover from a crash gracefully and the consequences are
acceptable (say, it may fail in 90% cases, but we can freely and
automatically retry until it succeeds... then it's perfectly reliable
for us.)

Anyway, tiny proofOfConcept code. Loads js entered in the box. Works in
FF 1.5.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html><head><title>The scriptload kitchen</title>

<script type="text/javascript">

function run(url)
{
newscr=document.createElement('script');
newscr.setAttribute("src",url)
document.body.appendChild(newscr);
}

</script>


</head><body>
<form name="inp" method="post" action="#">
<input type="text" value="http://www.kurs.horsesport.pl/inne/test.js"
name="txt">
<input type="button" value="run!"
onClick="run(document.inp.txt.value);" >
</form></body></html>

 

[Thomas 'PointedEars' Lahn]

Anyway, tiny proofOfConcept code.

That is no proof of concept whatsoever.

Loads js entered in the box. Works in FF 1.5.

It was not debated that it works in some browsers on certain occasions
with certain pieces of code. I have written such a function long
before but attached the necessary "caveat" section to its documentation.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">

No system identifier, triggering Quirks Mode.

<html><head><title>The scriptload kitchen</title>

No charset declaration, rendering this invalid if not served via HTTP.
But then, the document itself is already not Valid HTML 4.0.

<script type="text/javascript">

function run(url)
{
newscr=document.createElement('script');

^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^
Undeclared global variable; calling a (DOM) method without previous
feature-test.

newscr.setAttribute("src",url)

Not testing the return value of the (DOM) method called previously.

No need for setAttribute(), also standardized `newscr.src = ...'
suffices in all cases.

document.body.appendChild(newscr);
}

If, for example, I put document.write() somewhere in that script, the
document would be overwritten since it was already loaded. If we are
talking about JSON data instead, then it /may/ work.

Again: It was not debated that it is possible to append `script' elements
after the document was loaded; what was debated was that the outcome would
always be useful, and that it is possible to determine when or whether the
data was fully loaded.


PointedEars

 

[Robert]

Robert napisal(a):



I think Randy meant - "almost". 10% is so huge unreliablity that
between it and 90% the difference is marginal. Would you pick an
airplane that falls in 90% cases or one that falls in 10% cases

True, but it doesn't change the fact that the are not equally
unreliable. If for some reason you are forced to take one of these
planes which one would you take?
If they are (almost) equally unreliable it sounds like you don't have
much of a preference

 

[bwucke]

That is no proof of concept whatsoever.

It is. Proof that in -certain- cases it's possible. Means it makes
sense to move on. If it didn't work at all, ever, further debating
would be pointless. We'd have to move on to a different approach at
least.

It was not debated that it works in some browsers on certain occasions
with certain pieces of code.

I think it was. Two suggested approaches, one of them I think bound to
fail ("soft loading") and the other working at least in some cases, as
proven by example.

I have written such a function long
before but attached the necessary "caveat" section to its documentation.

Why didn't you post it then?!?

No system identifier, triggering Quirks Mode.
No charset declaration, rendering this invalid if not served via HTTP.
But then, the document itself is already not Valid HTML 4.0.
Undeclared global variable; calling a (DOM) method without previous
feature-test.
Not testing the return value of the (DOM) method called previously.
No need for setAttribute(), also standardized `newscr.src = ...'
suffices in all cases.

Agreed. Dirty code.
Still, it worked. Can be done, point proven, purpose of the code
achieved,how - not important.
Time to move on to cleanup of the code, testing compatiblity with other
browsers and implementing further features. Your turn? Supposedly, you
have the code already.

If, for example, I put document.write() somewhere in that script, the
document would be overwritten since it was already loaded. If we are
talking about JSON data instead, then it /may/ work.

There's more than one way you can break your own scripts.
document.write() works on the HTML text level. Probably this approach
(as well as innerHTML, textContent etc) would have to be replaced by
direct DOM tree calls (appendChild, createTextNode etc.)

Again: It was not debated that it is possible to append `script' elements
after the document was loaded; what was debated was that the outcome would
always be useful, and that it is possible to determine when or whether the
data was fully loaded.

Nope. In case of static text documents it wouldn't be useful, for sure.
In case of browsers not supporting Javascript it would not be useful.
Nothing is -always- useful. All we can hope for is, it will be robust
enough to be useful enough for our intended purposes. and we can learn
the level of usefulness.

So far you keep attacking whoever does a tiniest step outside the
rules, no matter what the general direction and what outcomes of their
step. Syntax nazi, standards nazi, netiquette nazi, but you seem
extremely reluctant to provide solutions yourself. Instead, whoever
says something new, you jump in, saying "I did it a long time ago,
better. You're dumb and I'm smart".

Maybe it's time to provide some actual content?

 

[Thomas 'PointedEars' Lahn]

That is no proof of concept whatsoever.

It is. Proof that in -certain- cases it's possible. [...]

But that was not what was to be proven.

I think it was.

No, that was not debated. Read again.

[...]

I have written such a function long
before but attached the necessary "caveat" section to its documentation.

Why didn't you post it then?!?

Why should I post something that I cannot even recommend?

Nope. In case of static text documents it wouldn't be useful, for sure.
In case of browsers not supporting Javascript it would not be useful.

And in case W3C DOM Level 2 HTML would not be supported as supposed or
the unspecified behavior that `script' element's contents is passed to
the script engine after the document has finished loading was not there.
And ...

[...]
So far you keep attacking whoever does a tiniest step outside the
rules, no matter what the general direction and what outcomes of their
step. Syntax nazi, standards nazi, netiquette nazi, [...]

Godwin's Law. You lose. And *PLONK*


PointedEars

 

[VK]

If, for example, I put document.write() somewhere in that script, the
document would be overwritten since it was already loaded.

This is why scriptObject.defer = true has been introduced and it's
being currently supported by all browsers I can get on hold of from my
windowed viewport. That means that the Mac world as well as the Unix
branch of evolution (Linux, Free BSD end Co.) is forcely is out of my
investigation. Volunteers are badly needed from the parallel worlds but
they seem to be indifferent to the project.

In the Windows Reality I'm locked in - the statement scriptObject.defer
= true seems to be the commonly accepted way to inform the interpreter
that the code to load will not change anyhow (or nullify) the existing
DOM structure. The acceptance of this flag among all browser versions
is still a subject of further investigation.

 

[Michael Winter]

On 23/12/2005 16:47, VK wrote:

[snip]

In the Windows Reality I'm locked in - the statement scriptObject.defer
= true seems to be the commonly accepted way to inform the interpreter
that the code to load will not change anyhow (or nullify) the existing
DOM structure.

The presence of the defer attribute doesn't mean that a script won't
modify the document tree. It is a /hint/ to the user agent that the
script can be executed at its leisure; that execution can be deferred.

The use of the defer attribute wouldn't be appropriate for a script that
calls the document.write method because the output from that call is
usually meant to be inserted just after the SCRIPT element that contains
it. If such a call were deferred, the output could possibly occur
anywhere, and that its position might even change on subsequent visits
(depending if and how a user agent chooses to defer).

The acceptance of this flag among all browser versions is still a
subject of further investigation.

It is, and it might not even be possible to determine that a particular
browser definitely does not defer (false negatives). A simple test could
look something like:

<script type="text/javascript">
var deferred = true;
</script>
<script type="text/javascript" defer>
deferred = false;
</script>
<script type="text/javascript">
alert('Deferred: ' + deferred);
</script>

and does indeed suggest that IE will defer execution.

Mike

 

[VK]

It is a /hint/ to the user agent that the
script can be executed at its leisure; that execution can be deferred.

*Any* trustwordy links about "defer" attribute? The best I've found so
far were exactly about the point: "a script with defer set to true will
deferred".
However sufficien from a "normal" point of view it would be, are there
any "abnormal" but more multiwordy comments about it?

 

[Thomas 'PointedEars' Lahn]

*Any* trustwordy links about "defer" attribute?

Yes, the HTML 4.01 Specification. It makes deferring such scripts a
possibility, not a recommendation or even a necessity.

The best I've found so
far were exactly about the point: "a script with defer set to true will
deferred".

Which most certainly is from the MSDN Library or another IE-related
resource.


PointedEars

 

[VK]

See also Dynodes Project at <http://www.mindsack.com/uxe/dynodes/>
and the quoted vot.sep. of JSON's inventor Douglas Crockford.

IMHO security issues with cross-domain script interchange is
over-appreciated. There are much more effective ways to bypass
same-domain limitations with malicious purposes. JavaScript adds
absolutely nothing extra in the pucture.

There are not any doable ways to have *full* browsing experience
*everywhere* across the Web in *absolutely secure* environment. There
are means to set security settings by domains, but this task is
accomplished on the higher level (security zones) and JavaScript per se
doesn't interfer neither affect to that.

 

[Michael Winter]

*Any* trustwordy links about "defer" attribute?

Trustworthy? There's nothing wrong with the W3C documentation in this
regard:

defer
When set, this boolean attribute provides a hint to the user
agent that the script is not going to generate any document
content (e.g., no "document.write" in javascript) and thus,
the user agent can continue parsing and rendering.
-- 18.2.1 The SCRIPT element, HTML 4.01 [1]

particularly when Microsoft's documentation says much the same (so no
threat to your 'reality'):

Using the attribute at design time can improve the download
performance of a page because the browser does not need to
parse and execute the script and can continue downloading and
parsing the page instead.
-- Remarks, DEFER Attribute | defer Property, MSDN [2]

It might be worth mentioning that the generating "document content"
comment above needn't apply to the DOM methods that operate at a node
level. As I wrote previously, the document.write method relies on the
positioning of the SCRIPT element that calls it, whereas the other
methods can target regions of the document tree explicitly. Their only
prerequisite is that that part of the document tree has already been parsed.

[snip]

Mike


[1] <http://www.w3.org/TR/html401/interact/scripts.html#h-18.2.1>
[2]
<http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/defer.asp>

 

[Lasse Reichstein Nielsen]

(e-mail address removed) wrote:

No system identifier, triggering Quirks Mode.

Actually not. The public identifier is for HTML 4.0 Strict, which
alone is enough to trigger standards mode.

/L

 

[bwucke]

It is. Proof that in -certain- cases it's possible. [...]

But that was not what was to be proven.

So what exactly was?

"Mission statement:

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

An external file containing stream (with some prerequisites, js syntax)
located on arbitrary location, capable of providing mostly arbitrary
data (including, by sequencing read, text stream) to the
document/application, using method other than xmlhttprequest was loaded
during runtime of already loaded document, not triggering/requiring
reload. I think it was what the whole mess is about. If I'm wrong,
please explain WHAT is to be proven.

Also,
- For serialized objects it will create unnecessary overheat plus
potential error stream.
* overhead is a cost. If the profits outweight the cost, it's fine. If
they don't, we still can develop the method and then think how to
reduce the costs.
* will 'defer' help with that?
- What would be possible is to determine if a certain variable was
declared and holding a value different from `undefined'.
* Won't 'defer' conflict with that?
- "loading scripts" after the document was loaded is still unreliable.
* given all prerequisites (Firefox [the script was written and tested
only for it]. Network connection, correct location of the files,
configuration allowing for kaunching javascript, and all the countless
other prerequisites like a user to click the button, a computer with
non-faulty hardware etc, this script is perfectly reliable. It uses
the same methods as the browser does internally for inserting nodes
into document, no matter what kind of node and no matter what time
(loading page or clicking a button) the node is inserted, so there's no
reason why it shouldn't work. And it works. And unless I missed
something serious [a prerequisite!] it will work. Thus it is reliable.
Point proven.

Would you care to explain, how is it more unreliable than sum of
unreliablity of dynamically loading any kind of content (even images)
and statically loading scripts together with all external objects on
standard page load?

No, that was not debated. Read again.

Many occasions when it might not work or work not as desired were
discussed. Prove all variants are true and you've proven the whole is
true. Prove one variant is false, and whole becomes doubtful, at least
reduce the set. The code for all the cases will be somehow similar to
this code, so it's a tool. It can't be used to prove things will never
fail, but can be used to find where they do and prove they do when they
do. Okay, I didn't prove anything you find interesting, doesn't make
the code useless. Of course it is dirty. I might fix it, but you say
you have cleaner, so why won't you post instead?

Why should I post something that I cannot even recommend?

You know, the empire of 3M was buitlt on fortune earned from Post-It
notes. They are an invention based on a glue invented some 80 years
earlier. The invention was archived because the author found the glue
is hopelessly weak, can barely keep two sheets of paper together.
Therefore, his reasoning was, the invention is useless. He couldn't
recommend the glue to anyone. And then someone digging in the archives
found the formula and got the idea that two sheets of paper barely
holding and easily separable is actually useful.

Post the code and maybe others will make it into something valuable and
find workarounds for the caveats.

And in case W3C DOM Level 2 HTML would not be supported as supposed or
the unspecified behavior that `script' element's contents is passed to
the script engine after the document has finished loading was not there.
And ...

and, and. Cars crash all the time. Claiming something is unreliable is
no reason not to develop it. There's no black and white, just a long
range of shades of grey. Pick one white enough for you or go back to
the caves.

So far you keep attacking whoever does a tiniest step outside the
rules, no matter what the general direction and what outcomes of their
step. Syntax nazi, standards nazi, netiquette nazi, [...]

Godwin's Law. You lose. And *PLONK*

Godwin's law means losing in groups that declare it. I read the FAQ
before posting the above, found no mention of Godwin, therefore no
plonk. You're a nazi.

 

[Thomas 'PointedEars' Lahn]

Actually not. The public identifier is for HTML 4.0 Strict, which
alone is enough to trigger standards mode.

Indeed. That should not happen since W3C HTML 4.0 has been
obsoleted by W3C HTML 4.01 and is not a standard anymore.


PointedEars

 

[VK]

..It appears that any modern standards compliant browser is able to
receive any data in base64 format (w/o reloading the page).

That was not the primary aim (I was thinking more about <script>
implants) but it happened to be a side effect of ruling out different
possibilities plus reading posts in this thread. The last hint came
from Lasse Reichstein Nielsen - not from the message itself but from
the bottom signature about DHTML Death Colors:
<URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>

So shall we call it JSONet Project with branches
JSONet S (expoiting external style sheet idea)
and
JSONet J (exploiting script implants)
?

Proof of concept (tested under Firefox 1.5 under Windows 98 SE)

/// HTML FILE ///

<html>
<head>
<title>JSONet</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">

<script type="text/javascript">
var sid = '';

function init() {
var roof = document.getElementsByTagName('HEAD')[0];
var JSONet = document.createElement('LINK');
sid = 'jsn' + (new Date()).getTime();
with (JSONet) {
id = sid;
title = 'JSONet S';
rel = 'alternate stylesheet';
type = 'text/css';
href = 'data.css';
}
roof.appendChild(JSONet);
roof.normalize();
setTimeout(reader,500);
}

function reader() {
var out = document.forms[0].out;
var sty = document.getElementById(sid).
sheet.cssRules[0].
style.backgroundImage;
var str = sty.split(',')[1];
var b64 = str.substring(0,str.length-1);
var mes = atob(b64);
out.value = mes;
}
</script>
</head>

<body onload="init()">

<form method="post" action="">
<textarea name="out" cols="64" rows="8"></textarea>
</form>

</body>
</html>

/// CSS Sheet called <data.css> ///
..data {
background-image:
url(data:image/png;base64,SGFwcHkgTmV3IFllYXIgMjAwNiE=);
}

/// RESULT ///
base64 string contains the message "Happy New Year 2006!" which you'll
see on the page in the textarea.

 

[VK]

Indeed. That should not happen since W3C HTML 4.0 has been
obsoleted by W3C HTML 4.01 and is not a standard anymore.

IE does not have HTML 4.01 in its "registered doctypes" table. So
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> may work for
switching into strict mode but only by the "Unrecognized !DOCTYPE"
rule.

Details at:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnie60/html/cssenhancements.asp>

(after the MSDN site redesign you may need to have IE 5.5 or higher
under Windows 98 SE or higher to be able to access the information).

 

[Lasse Reichstein Nielsen]

IE does not have HTML 4.01 in its "registered doctypes" table. So
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"> may work for
switching into strict mode but only by the "Unrecognized !DOCTYPE"
rule.

A plausible theory, but not the way it is, sadly.
If IE simply didn't recognize HTML 4.01 doctypes, then the declaration
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
should trigger standards mode. It doesn't. IE6 goes into CompatMode
on this declaration, but standards mode with a system identifier,
so it treats HTML 4.01 just as HTML 4.0.

Perhaps the table is just not complete (probably because it was
written before HTML 4.01 was finalized, although I haven't checked
the dates).

/L

 

[VK]

For cross-browser tests of different JSONet variants one can found
useful:

"Using JSON with Yahoo! Web Services"
<http://developer.yahoo.net/common/json.html>