Re: Banana Republic (was Re: OpenVMS Book Wins award)

Richard Maher wrote:
Hi Mark,

"Mark Daniel" <mark.daniel@xxxxxxxxxx> wrote in message
news:01577c42$0$20645$c3e8da3@xxxxxxxxxxxxxxxxxxxx
[XHR Ajax methos. . .]
Only when finished is the response data (body) signaled as available
for subsequent processing.
: : : :
: :
Technically the body fragment received (so far) is available any time
during the 'body being received' state but AIUI, although there is a
state-change event when it begins being received, and another when it is
fully received, there is no event associated with the receipt of each
transmission fragment (if multiple) of that body (each containing the
datum or data in MONDESI's case). This means the in-browser application
code would need to poll internally, for instance checking the length of
the fragment to detect the arrival of new data. Obviously less elegant.

Thanks for clearing that up. I had seen Ajax used in a quasi-push/long-poll
page but didn't look deeeply enough to see that the client was having to
poll the received data for additions. That is disappointing.

It may not be the case. I am qualifying much of this with "As I
Understand It" (AIUI). I'm only involved as a pastime. It's hardly a
specialisation. Fiddling under the hood of <you-name-it> also is often
overtaken by the more prosaic aspects of supporting WASD (also a pastime).

Using a loading IFRAME the MONDESI response is always accessible to the
DOM which allows a single request to supply asynchronous data (via
streamed JavaScript calls) to the application for as long as the
connection persists.

I have had a quick look but am still at a loss as to which tags constitute a
unit of renderable data and whether a closing tag is sufficient to delimit a
transmission.

Fair point. In the more general case neither am I. And it probably
varies on a per-browser basis. A reasonable bet is that the newline
character (0x0a) is required as a 'record' delimiter. Unless or until a
record has that terminator it's unlikely that a parser (HTML or
otherwise) will be (re)invoked. However <SCRIPT>..</SCRIPT> clauses are
parsed and processed during page loading

http://www.w3schools.com/js/js_howto.asp
http://www.w3schools.com/js/js_whereto.asp

so it's just a matter of ensuring each data update provided by MONDESI
is a newline terminated, <SCRIPT>..</SCRIPT> delimited, set of
JavaScript calls.

What must also be disabled is any sort of proxy caching (as much as one
can) and encoding (which can change transmission fragmentation). These
can be seen in the response header code (and are WASD
optimisations/idiosyncrasies)

fprintf (stdout,
"Status: 200\n\
Content-Type: text/html\n\
Script-Control: X-stream-mode=1\n\
Script-Control: X-content-encoding-gzip=0\n\
Pragma: no-cache\n\
Cache-Control: no-cache, no-store, private\n\
\n\
<body onload=\"parent.mdsInitialStart();\">\n");
fflush (stdout);

Or what the mdsToMsgChannel() does for that matter. Are
IFRAMEs not able to take advantage of the usual simple inter-frame Variable
and Function acccess?

MONDESI was designed to allow monitoring of multiple, disparate hosts
from the one browser page. There is a parent page, then inside that an
<IFRAME> instantiated, visible monitor display from each host (even if
only the one). Inside each of these is the non-visible data collection
<IFRAME> (for the same host).

+-------------------------------------------------------------+
| http://host.domain1/ |
| +---------------------------------------------------+ |
| | <IFRAME http://host.domain2/></IFRAME> | |
| | <IFRAME 'hidden' http://host.domain2/></IFRAME> | |
| +---------------------------------------------------+ |
| +---------------------------------------------------+ |
| | <IFRAME http://host.domain3/></IFRAME> | |
| | <IFRAME 'hidden' http://host.domain3/></IFRAME> | |
| +---------------------------------------------------+ |
| +---------------------------------------------------+ |
| | <IFRAME http://host.domain4/></IFRAME> | |
| | <IFRAME 'hidden' http://host.domain4/></IFRAME> | |
| +---------------------------------------------------+ |
+-------------------------------------------------------------+

Note that in this example all are accessed from not only different hosts
but different domains as well. The complication arises because of the
design objective of being able to have the history display occluded (to
save browser real estate) or visible as required. This has to be
effected in the DOM of the parent page. However the button to allow
this change should be aggregated with the other controls, that is within
the per-host display (inside the <IFRAME>). Immediately there is a
cross-site scripting constraint exercised by the browser (to prevent XSS
hacks). No straight-forward inter-frame comms allowed. (Of course for
the best-case, parent and monitor display from the same host, this would
not be an issue but for the worst-case, disparate domains, it would, and
therefore had to be catered for.) mdsToMsgChannel() just abstracts
those comms for the generational differences of HTML5 and HTML4 capable
browsers. Data delivery from the hidden <IFRAME> into the monitor
display is via direct inter-frame comms because both will always be from
the same host.

Anyway, the functionality in MONDESI demands much more than a quick look,
and I will flounder on. Once more, well done.

It is a *lot* like having teeth drilled. But for this exercise I wanted
the understanding gained from the pain (very Platonic :-) Of course in
the real world you would use one of the JavaScript toolkits

http://en.wikipedia.org/wiki/List_of_Ajax_frameworks

that are about. These are like the procaine of dentistry. The
immediate discomfort has gone leaving you able to concentrate on the two
arms up to their elbows inside your head.

I like the look of Dojo and may use it (sometime in the future) to
implement a more sophisticated HMI and Ajaxian behaviour for soyMAIL.

http://wasd.vsm.com.au/doc/scripting/scripting_0100.html#035a562e

(looks like you're not reviewing the class notes :-)

I did look up the link you provided but even the sheer amount of
documentation for WASD is a bit daunting, even to the less lazy. It's
certainly an impressive body of work!

Invariably it's feast or famine :-)

(And we know this is an opportunity to note the lack of an inherent
asynchronous, bidirectional channel between application and server but
that is not pertinent because, at least on my part, this is a discussion
about an HTTP based application and not the vagaries of HTTP itself. I
am too old to engage in ideological diatribe. That is for the young and
the bitter.)

Let's not leave out the old and bitter :-)

The young and the bitter may be intersecting subsets but in any case why
deliberately would I abnegate my own disposition? ;-)

Look sorry if it's impertinent
but what is outside any HTTP protocol is "when a server gets told something"
in this case "stop what your doing". I don't want to labour the point, just
satisfy my curiosity that if a user gets fed up waiting or the server gets
stuck then he moves on to the next server process, and the next . . .
potentially leaving a series of dangling servers wasting resources until
their next stdout. No big deal.

Well of course that can happen. Depends on server design and
configuration. WASD for instance does exactly that deliberately (well,
by default but can be optioned) for scripts. And the objective is to
conserve resources (perversely enough :-) VMS process creation is *so*
expensive, and some application environments likewise (scripting engines
for example), that it is better economy, if a client breaks the
connection, to allow a script to run to completion rather than try and
shut it down (kill the process or image). The server just throws away
the output in the absence of the client, leaving the script or
application intact and available for the next request.

http://wasd.vsm.com.au/doc/scripting/scripting_0100.html#0625af2c

IMO; when an HTTP request is accepted for processing by a server, if
that request can be processed to completion, it probably should,
particularly for POSTs, PUTs, DELETEs, etc., regardless of whether the
client remains connected. After-all, that's what the client asked for.
Of course it also depends on design goals.

The image rundown feature was suggested and implemented during 2001 (per
JFP IIRC) specifically for a company's database environment but

The one I'd really like (and is available internal from Rdb) is the ability
to abort a long running query! (No just long "compile" as in the old days.)
Rdb engineering introduced this functionality (via logical name timeout
IIRC) and should be available as a supported API!

subsequently has proved valuable in a range of others. It works well
enough to avoid triggering any sort of unintended checkpointing,
recovery, rollback, etc., by allowing instances to be gracefully
released during non-normal processing.

Certainly better than a Monitor Freeze-Lock and rollback! But I do have to
wonder again why the users were aborting their sessions and whether an
alternative solution would be more appropriate here. (To the problem of
interrupting Rdb regardless of server architecture)

8< snip 8< another impressive flying forward one and one half
somersault
with pike 8< snip 8<
Come on, Mark. You've got one dedicated process (or was it thread?) per
client, and then if you want to change anything you have to cancel the
first
long-poll and then take out another one. I think at least one "bollocks"
is
entitled to be left in situ, don't you :-)
If it's testes you're after then I'll leave these in place for you.

Bit tetchy (testy) today?

Neither were very punny :-)

Anyway, I will look at the Javascript when it's available on Deathrow or
It's live on ~deathrow~

http://deathrow.vistech.net/cgi-bin/mondesi

Again, well done!

elsewhere. BTW was JFP's ever released into the wild or did he/they end
up
selling it to someone?

Anyone seen hide nor hair of it?

I'm sure JFP keeps an eye on c.o.v. when he has the time. Let's hope
currently he hasn't!

I was hoping they'd dropped to all-Flex front-end and
gone the FABridge route like NASDAQ and
http://manson.vistech.net/t3$examples/demo_client_flex.html So much more
flexible (no pun intended) and feature-rich, don't you think?
...and a rhetorical answer.

I was just wondering if you were making a point of using a Javascript-only
solution and ensuring that no plug-in was reqd, whether you were aware of
the FABridge from Adobe that at first glance would allow your server to dish
stuff up to Flex-Charts, or whether you just think Walter's graphing
capabilities are more than sufficient?

It's a kludge. Sufficient to purpose and remarkable for what it
achieves using only <DIV>s and the DOM but hardly *the* solution. An
early response to the absence of broad cross-browser scalable vector
graphics support. Many of the toolkits mentioned above now contain
capable wrappers around recent browser SVG implementations. I chose the
WZ kit because it was small and self-contained (and I'd used it before).
MONDESI was more about other stuff (though when you end up trying to
make something useful as well the old 80:20 rule kicks in).

[I'm thinking this dialogue has just about run its course...]

Suite yourself, I certainly don't want to upset anyone (Not here anyway :-)

It was disconcerting to be used as a launchpad into what could only
consider a rant. Apart from that ...

But I guess it would be more interesting and less drawn out with more than
just the two of us.

Perhaps if the perversity of heat-pumping was touched upon ... no
matter in which direction the heat is being exchanged, the more you need
it the less efficient it becomes ... done!

Anyway, sorry to be slow, but if anyone else would care to explain Mark's
use of the iFrame here (or a pointer to a simpler page) and why the regular
inter-frame communication techniques are insufficient then I'm all ears.
(And yes I have read the not insubstantial amount of comments in the code)
Is the iFrame simply made "visible" or is there an event triggered and data
plucked from the iFrame for rendering elsewhere, and are we looking at a
case of cross-domain Javascript here?

Cheers Richard Maher

.