[Info-vax] Banana Republic (was Re: OpenVMS Book Wins award)

[Richard Maher]

Hi Mark,

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

I'm guessing you're also not independantly wealthy either, so are you still
in the navy so to speak (and no excuse for singing :-) I had a friend
working as a BA at Garden Island and inquired about development
opportunities there and he told me that although they used to have a VAX
lying around somewhere, all they really do is clean the windscreen and
change the oil on the submarines and send 'em back to S.A. for anything
interesting.

With regard to Ajax and ready-state 3, it appears that Gecko-based browsers
such as FireFox in fact do fire a readystatechange handler more than once
with the received data being available for access. The terminology used was
"chunk" which gave me the impression it referred to your beloved HTTP 1.1
content-encoding "chunked". Anyway, for the interested, below are some
links/references I found on my travels: -

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Gecko-based browsers: -
http://en.wikipedia.org/wiki/Comet_(programming)

Also: -
"There's a good writeup in "Javascript: The Definitive Guide" 5th edition,
page 484. It's worth reading and understanding. For those that don't have
the guide, it basically says Mozilla interprets readyState 3 as a state
change for transferring data. Each chunk of data resets readyState 3 to
readyState 3 and puts the current available data in the responseText field.
Microsoft interprets it as a single state change, meaning when it hits
readyState 3, data is in the process of being delivered. The data is only
available when it hits readyState 4. Safari has similar behavior and
performs some buffering prior to setting the responseText field."

HTTP Sow's Ear (Doctor, it really hurts when I use HTTP!)
http://cometdaily.com/2008/01/17/proposal-for-native-comet-support-for-browsers/
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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

Makes sense, thanks for the explanation.

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

Yes this does sound like a plug for Tier3 (and probably is :-) but surely
the ideal then would be to avoid process/image startup and rundown o/head
yet *still communicate to the server that the client has gone* and have the
application-specific logic determine what to do next?

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

Personally, I've never been a fan of heuristic transaction completion!

Having spent a fair bit of time with two-phase commit protocols and
integrating MTS/DTC with DECdtm, I am a firm believer in the part ACID has
to play in serious business transactions. Not that any of the many dickheads
in VMS middle-management have the faintest idea of how WS-AT would ever be
implemented on VMS except perhaps "Oh, we're really hoping Oracle will just
do something".

But if you can act autonomously or in isolation and nothing ever goes wrong
then why not just soldier-on I suppose?

WS-Coordination? Business-Activity transactions? Compensatory actions and
transactions? Yeah all sounds delightful :-(

> After-all, that's what the client asked for.

Perhaps, but is the client not allowed to change their mind? For example, do
you run with $SET NOCONTROL=Y

If all data-wharehouse joins or "delete from employees" were able to run to
completion in the abscence of reasnable selection criteria, then we could
quickly end up in a pickle. Thankfully most databases (even *some* MySQL
implementations) require a COMMIT to seal the deal. But I'm guessing that
with HTTP's fire-and-forget you'd have no choice but to vote for an implicit
commit here anyway?  The SQL (standard) default action is to commit
outstanding transactions at image exit, so you're definitely not alone.

>   Of course it also depends on design goals.

Quite.

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

Can't help it, bit like Tourettes :-) Don't take it personally.

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

I still often favour the "hit it with a hammer" school of thought.

Speaking of heat pumps though, looks pretty cold up top at the moment!
Hasn't been under 30 degrees here all year; you're probably the same?

Cheers Richard Maher

Note: All "degrees" mentioned in this story were measured in Celsius thus
making 30 very pleasant, it's a bit like metres and kilometres (or meters
and kilometers)

"Mark Daniel" <mark.daniel at vsm.com.au> wrote in message
news:015f695a$0$20615$c3e8da3 at news.astraweb.com...
> Richard Maher wrote:
> > Hi Mark,
> >
> > "Mark Daniel" <mark.daniel at vsm.com.au> wrote in message
> > news:01577c42$0$20645$c3e8da3 at news.astraweb.com...
> > [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
>