Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Mark Daniel <mark.daniel@xxxxxxxxxx>
- Date: Tue, 16 Dec 2008 22:01:26 +1030
Richard Maher wrote:
8< snip 8<
MONDESI activates the data collection stream by creating a hidden IFRAME
element and adding it using appendChild()
Obviouly several ways to skin a cat but is there anything other than
personal preference that made you go the iFrame route rather than XHR? I
would've thought Ajax to be more feature-rich; any behavioural differences
that you're drawing on? Don't you get some sort of "data available" event
with XHR that could process the arriving stats pack at each poll interval?
Does it really matter - probably not.
Certainly cats and skins but in this case, yes. The XHR object life cycle has five stages; basically from 'created' (but uninitialised), to 'opened' (initialised and from this can be sent), to 'response headers received,' to response 'body being received', and finally to 'complete'. Only when finished is the response data (body) signaled as available for subsequent processing. This might be suitable if MONDESI was a polling application. It's not.
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.
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.
quiesce? SoDoes it have to wait for the server("collection application") tounlike your nano-second stuff, if the server was locked on a database orWould depend on the design. What do 'usual applications' do? Depends
looping away madly then would we just have to wait?
entirely.
What tools do you have in the box? Have you got something more subtle and
intelligent than a $delprc or $forcex? (And has anyone worked out the Rdb
"cancel" API yet?)
Nothing more than what's available to CGI; <stdin>, <stdout>, <stderr>, and a few strings. Oh, and WASD's integration with VMS. The HTTP Web is stateless, largely RESTful and the only implicit back-channel is that of the connection status.
As previously referred
http://groups.google.com/group/comp.os.vms/msg/d43489f321400e1d
In the case of a server-initiated script rundown WASD issues a $FORCEX to an image to allow handlers to be invoked
http://wasd.vsm.com.au/doc/scripting/scripting_0100.html#035a562e
(looks like you're not reviewing the class notes :-)
In the case of a script concluding its processing normally, the closure of the output stream is noted by the server and the client connection appropriately post-processed. The long-poll used by MONDESI must be considered a useful but somewhat extreme case of the scripting paradigm, where the end of processing is essentially forced by connection closure for one of multiple, external reasons.
(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.)
The image rundown feature was suggested and implemented during 2001 (per JFP IIRC) specifically for a company's database environment but 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.
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.
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
(thanks guys) and the source is available
http://deathrow.vistech.net/ht_root/src/mondesi/
http://wasd.vsm.com.au/ht_root/src/mondesi/
http://wasd.vsm.com.au/wasd/
elsewhere. BTW was JFP's ever released into the wild or did he/they end up
selling it to someone? 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.
Cheers Richard Maher
[I'm thinking this dialogue has just about run its course...]
.
- Follow-Ups:
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Richard Maher
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- References:
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Richard Maher
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Mark Daniel
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Richard Maher
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Mark Daniel
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Richard Maher
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Mark Daniel
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- From: Richard Maher
- Re: Banana Republic (was Re: OpenVMS Book Wins award)
- Prev by Date: Re: Basestar, OPC transport users somewhere??
- Next by Date: Re: hobby cd
- Previous by thread: Re: Banana Republic (was Re: OpenVMS Book Wins award)
- Next by thread: Re: Banana Republic (was Re: OpenVMS Book Wins award)
- Index(es):
Relevant Pages
|