OpenVMS Book Wins award
yyyc186
Roland Hughes
Award-Winner in the Business: Technology/Computers/Internet category
of the National Best Books 2008 Awards, sponsored by USA Book News
You can find this book in Island Computer's Web store.
David Turner, islandco.com
Finally...
--
David B Turner
=============================================
Island Computers US Corp
PO Box 86
Tybee GA 31328
Toll Free: 1-877 636 4332 x201, Mobile x251
Email: dtu...@islandco.com
International & Local: (001)- 404-806-7749
Fax: 912 786 8505
Web: www.islandco.com
=============================================
"yyyc186" <yyy...@hughes.net> wrote in message
news:ee65a5f3-cba1-40a5...@o4g2000pra.googlegroups.com...
Main, Kerry
Hey, very coooll ..
:-)
Additional info:
http://www.usabooknews.com/bestbooksawards2008.html
scroll down to:
Business: Technology/Computers/Internet
Winner:
The Minimum You Need to Know About Service Oriented Architecture by Roland Hughes Logikal Solutions
ISBN 978-0-9770866-6-5
Some earlier feedback on the book:
http://www.openvms.org/stories.php?story=08/09/27/8565098
Regards
Kerry Main
Senior Consultant
HP Services Canada
Voice: 613-254-8911
Fax: 613-591-4477
kerryDOTmainAThpDOTcom
(remove the DOT's and AT)
OpenVMS - the secure, multi-site OS that just works.
Rich Jordan
Congratulations, Roland. That is wonderful.
Rich
IanMiller
This is the part where the people around here who have not bought one
of Roland's book rush to island computers web site and buy one.
...
yyyc186
ROFLMAO
Somehow I doubt that will happen Ian, but thanks for the thought!
Roland
David J Dachtera
Great job, Roland!
Excellent!
D.J.D.
Mark Daniel
> The Minimum You Need to Know About Service Orieted Architecture by
> Roland Hughes
>
> Award-Winner in the Business: Technology/Computers/Internet category
> of the National Best Books 2008 Awards, sponsored by USA Book News
Congratulations Roland!
(I purchased it when AU$ was almost at US$ parity :-)
Richard Maher
> (I purchased it when AU$ was almost at US$ parity :-)
Aaah, it seems like only weeks ago :-(
Cheers Richard Maher
PS. Just in case you don't subscribe to the WHATWG mailing list, do you have
any interest in, or opinions on the following: -
----- Original Message -----
From: "Shannon"
To: "WHAT working group" >
Sent: Tuesday, October 14, 2008 7:22 AM
Subject: [whatwg] WebSocket and proxies
> In the process of testing my WebSocket proposal I discovered the CONNECT
> method has a major restriction. Most proxies disable CONNECT to anything
> but port 443.
>
> The following is from "Squid and the Blowfish":
> ------------------
> It is very important that you stop CONNECT type requests to non-SSL
> ports. The CONNECT method allows data transfer in any direction at any
> time, regardless of the transport protocol used. As a consequence, a
> malicious user could telnet(1) to a (very) badly configured proxy, enter
> something like:
> ... snip example ...
> and end up connected to the remote server, as if the connection was
> originated by the proxy.
> -------------------
>
> I verified that Squid and all public proxies I tried disable CONNECT by
> default to non-SSL ports. It's unlikely many internet hosts will have
> 443 available for WebSockets if they also run a webserver. It could be
> done with virtual IPs or dedicated hosts but this imposes complex
> requirements and costs over alternatives like CGI.
>
> The availability and capabilities of the OPTIONS and GET protocols also
> varied from proxy to proxy. The IETF draft related to TLS
> (http://tools.ietf.org/html/draft-ietf-tls-http-upgrade-05) has this to
say:
>
> -------------------
> 3.2 Mandatory Upgrade
>
> If an unsecured response would be unacceptable, a client MUST send
> an OPTIONS request first to complete the switch to TLS/1.0 (if
> possible).
>
> OPTIONS * HTTP/1.1
> Host: example.bank.com
> Upgrade: TLS/1.0
> Connection: Upgrade
> -------------------
>
> So according to this draft spec OPTIONS is the only way to do a
> *mandatory* upgrade of our connection. Once again this failed in testing
>
> -------------------
> => OPTIONS * HTTP/1.1
> => Proxy-Connection: keep-alive
> => Connection: Upgrade
> => Upgrade: WebSocket/1.0
> => Host: warriorhut.org:8000
> =>
> <= HTTP/1.0 400 Bad Request
> <= Server: squid/3.0.STABLE8
> --------------------
>
> Other proxies gave different errors or simply returned nothing. The
> problem may be related to the Upgrade and Connection headers rather than
> OPTIONS, since I had similar issues using Connection: Upgrade with GET.
>
> I had the most success using GET without a Connection: Upgrade header.
> It seems that the proxy thinks the header is directed at it so it does
> not pass it on to the remote host. In many cases it will abort the
> connection. Using the Upgrade: header without Connection allows the
> Upgrade header through to the actual websocket service.
>
> It seems to me that whatever we try in many cases the connection will be
> silently dropped by the proxy and the reasons will be unclear due to the
> lack of error handling. There seems to be a wide variation in proxy
> behaviour for uncommon operations. I suppose proxy developers could fix
> these issues but whether a significant rollout could be achieved before
> HTML5 is released is questionable.
>
> Given that an asynchronous connection cannot be cached the only reasons
> remaining for going through a proxy are anonymity and firewall
> traversal. Automatically bypassing the users proxy configuration to
> solve the issues above has the potential to break both of these. It
> would be a significant breach of trust for a UA to bypass the users
> proxy and some networks only allow connections via a proxy (for security
> and monitoring).
>
> It seems that we're stuck between a rock and hard place here. In light
> of this I reiterate my earlier suggestion that the time could be better
> spent providing guidelines for communication via an asynchronous CGI
> interface. This would allow reuse of existing port 80 and 443 web
> services which would resolve the cross-domain issues (the CGI can relay
> the actual service via a backend connection) and most of the proxy
> issues above (since proxy GET and CONNECT are more reliable on these
ports).
>
> Shannon
>
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:01110d0c$0$20616$c3e...@news.astraweb.com...
Mark Daniel
> Hi Mark,
>
>> (I purchased it when AU$ was almost at US$ parity :-)
>
> Aaah, it seems like only weeks ago :-(
I bought it through Barnes and Noble in late May '08 for US$36.00 plus
US$13.00 P&P, and I think my credit card statement said something like
AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
at US$0.65 now escapes me - perhaps that's one reason I'm still working
for wages.
It was a good 'background' read but not directly applicable to my
daytime duty statement these days. I had not (as I indicated to Roland
I might) gotten around to a public review (that would have required a
second read). Willem Grooters provided one I'd generally endorse.
At around the same time I purchased Heller's, "Catch 22" (shipped to one
of my daughters), Earl's, "Digital Equipment Corporation (MA) (Images
of America)", and Schein's, "DEC Is Dead, Long Live DEC"; all good
reads and all for different reasons. With the exchange rate more like
2:3 I might have to think think more carefully. (The Earl soft-cover is
a particularly easy but also interesting 'read' I'd recommend to all
interested in DEC :-)
> Cheers Richard Maher
>
> PS. Just in case you don't subscribe to the WHATWG mailing list, do you have
> any interest in, or opinions on the following: -
No I don't and indirectly I guess I do.
That any network connectivity has some sandboxing doesn't exactly
surprise me. A network conduit (like SSH or HTTP CONNECT) is carte
blanche for whatever the agent wishes to transfer. No constraint would
be considered negligence.
I'm guessing you mention this because the suggestion below that
"that the time could be better spent providing guidelines for
communication via an asynchronous CGI [originally I read GUI :-]
interface."
sounds remarkably like Tier3 :-)
I agree; why would anyone spend time abstracting interfaces if a
monolithic solution is all that is currently required? Of course this
is an entirely fresh (if not novel) discussion point ...
Richard Maher
Thanks for the reply.
> I bought it through Barnes and Noble in late May '08 for US$36.00 plus
> US$13.00 P&P, and I think my credit card statement said something like
> AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
> at US$0.65 now escapes me - perhaps that's one reason I'm still working
> for wages.
I looked seriously at Perth Mint gold in August (when the bank deposit
guarantee was sweet FA) and Foreign Currency accounts aren't as common here
as they are in the UK. Either way I would (and have) lost big time - but
haven't we all :-(
> That any network connectivity has some sandboxing doesn't exactly
> surprise me.
Me either! I'm a big fan of the same-origin, or codebase, policy for Applets
but these guys just want to keep pushing the envelope.
> A network conduit (like SSH or HTTP CONNECT) is carte
> blanche for whatever the agent wishes to transfer. No constraint would
> be considered negligence.
Yeah, but here I bow to your much greater experience and ask "What the hell
can a *Socket not HTTP* proxy-server do for me?". Look I wanted a HTTP
CONNECT handshake to give me a Tunnel for my Socket over a httpS connection
to an arbitray TCP/IP server, but it doesn't look doable; please advise.
I also view with interest what the Comet guys are doing with Orbited (see
www.cometdaily.com for some background) as they don't seem to be bound by
(or have already solved) these proxy-server restrictions.
> I'm guessing you mention this because the suggestion below that
>
> "that the time could be better spent providing guidelines for
> communication via an asynchronous CGI [originally I read GUI :-]
> interface."
>
> sounds remarkably like Tier3 :-)
Damn, I'm as transparent and one-domensional as usual :-)
The way I see it is we have two camps (and I'm happy to live with the
pluralism and think there's enough room for everyone).
1) The WebSockets http/html5 guys who have the distinct (and only) advantage
of being able to tunnel out of 80/443 as HTTP
2) The New Order of full-blown, connection-oriented, full-duplex, binary,
Socket Interaction
If Sockets can't traverse public proxy-servers with existing HTTP then
option 1 is no longer on the table as far as I can see?
Anyway, please let me ask the question of why anyone would want to use a
proxy-server for Socket communication?
. Socket Cacheing - No Thanks
. Limited client IP addresses - IPV6
. Anonymity - Not always a good thing
. Firewall - Open up connections to/from valid hosts/ports
. Monitoring/filtering - Requirements spec for binary data
Cheers Richard Maher
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:011308d4$0$20645$c3e...@news.astraweb.com...
Mark Daniel
> Hi Mark,
>
>
>> I bought it through Barnes and Noble in late May '08 for US$36.00 plus
>> US$13.00 P&P, and I think my credit card statement said something like
>> AU$52.00 so it was right at the 'peak'. Why the AU$ currently should be
>> at US$0.65 now escapes me - perhaps that's one reason I'm still working
>> for wages.
>
> I looked seriously at Perth Mint gold in August (when the bank deposit
> guarantee was sweet FA) and Foreign Currency accounts aren't as common here
> as they are in the UK. Either way I would (and have) lost big time - but
> haven't we all :-(
>
>> That any network connectivity has some sandboxing doesn't exactly
>> surprise me.
>
> Me either! I'm a big fan of the same-origin, or codebase, policy for Applets
> but these guys just want to keep pushing the envelope.
I noted the post on Adobe policy files.
>> A network conduit (like SSH or HTTP CONNECT) is carte
>> blanche for whatever the agent wishes to transfer. No constraint would
>> be considered negligence.
>
> Yeah, but here I bow
;-)
> to your much greater experience and ask "What the hell
> can a *Socket not HTTP* proxy-server do for me?".
Isn't a(n IP) socket proxy that doesn't explicitly talk HTTP during
setup a one-to-one NAT router? And if accepting external connection
requests, a static port mapping NAT router, into/through the DMZ and
onto internal services? And so forth through the NAT variants.
> Look I wanted a HTTP
> CONNECT handshake to give me a Tunnel for my Socket over a httpS connection
> to an arbitray TCP/IP server, but it doesn't look doable; please advise.
I can but reframe my previous comment; unconstrained connectivity from
browser based applications is surely like signing a full book of blank
cheques.
> I also view with interest what the Comet guys are doing with Orbited (see
> www.cometdaily.com for some background) as they don't seem to be bound by
> (or have already solved) these proxy-server restrictions.
AIUI; Orbited is a service used to accept Web-style socket connection
requests from browsers, establish Comet-style, bidirectional
communication with the browser, then proxy (or forward, or gateway, or
<whatever-you-feel-comfortable-describing-it-as>) that communication via
a TCP socket to the requested end-point. Without some sort of access
control it functions as an open relay - carte blanche. With access
control it's a lot like most CONNECT proxy, or at least CONNECT
reverse-proxy. Of course it's a bit more than that (but isn't
everything!) Until Web Sockets become commonplace it uses a number of
approaches to *emulate* asynchronous comms with current browsers.
AIUI; Comet is a broad term used to described leveraging HTTP
server-push of unsolicited/unpolled/asynchronous data to the browser,
using existing HTTP technologies, most commonly, though not restricted
to, streaming of a series individual response data 'inside' a persisting
HTTP connection, currently via 'long polling' and XMLhttpRequest() or
<script> tag instances. It's a compromise hack. Not perfect but it
works. Of course it's more than this (but then isn't everything!)
Undoubtably it will(/is) develop(ing) to encompass Web Sockets, etc.
Both are broad, evolving concepts and implementations.
FYIW; I have an (as-yet) unpublished Web application displaying
elementary graphs of $GETRMI (monitor) data. It uses a Comet-style
<IFRAME> and streaming long-poll. When system data changes it generates
a <script>ed function call into browser JavaScript that supplies data
values which the application JavaScript then graphs or displays. One
buffered I/O of a few tens to a few hundreds of bytes (depending on what
data have changed) per sample period. Negligible CPU ticks. Not
full-duplex but not synchronous-poll either.
>> I'm guessing you mention this because the suggestion below that
>>
>> "that the time could be better spent providing guidelines for
>> communication via an asynchronous CGI [originally I read GUI :-]
>> interface."
>>
>> sounds remarkably like Tier3 :-)
>
> Damn, I'm as transparent and one-domensional as usual :-)
>
> The way I see it is we have two camps (and I'm happy to live with the
> pluralism and think there's enough room for everyone).
>
> 1) The WebSockets http/html5 guys who have the distinct (and only) advantage
> of being able to tunnel out of 80/443 as HTTP
If you mean, provide asynchronous (event triggered), binary (non-HTTP)
comms using these ports then yes. Of course there is no reason why the
services requested over these ports cannot further proxy the binary to
TCP anything-configured. IMO the bottom line is (again) access-control.
Whether this is the lone advantage is moot.
Of course Web Sockets require specialised server (and proxy server) as
well as client (browser) support.
The WASD mudmap includes Web Sockets server support (either 10.0 in
mid-'09, or 10.1 in mid-'10). Perhaps once HTML5 moves from draft :-}
> 2) The New Order of full-blown, connection-oriented, full-duplex, binary,
> Socket Interaction
No doubt this will be remarkably versatile in the absence of sandboxing,
with many-and-varied conduits established between user's browsers and
all manner of 'services'.
> If Sockets can't traverse public proxy-servers with existing HTTP then
> option 1 is no longer on the table as far as I can see?
This one has lost me but I'll have a go at two of the possible intents:
1) If you mean Web Sockets can't through existing HTTP proxy then the
answer seems to me that they are designed to do just that. Web Sockets
behind proxy servers know it and appropriately CONNECT to tunnel.
2) If you mean TCP sockets can't then no, unless they speak the
application-level protocol required by the proxy (which would make them
Web Sockets for all intents and purposes :-)
> Anyway, please let me ask the question of why anyone would want to use a
> proxy-server for Socket communication?
>
> . Socket Cacheing - No Thanks
Difficult to cache without meta-data.
> . Limited client IP addresses - IPV6
Still a ways off. And there's always the private/public address thingy.
> . Anonymity - Not always a good thing
Internal opacity usually is a good thing.
> . Firewall - Open up connections to/from valid hosts/ports
Access control usually is a good thing.
> . Monitoring/filtering - Requirements spec for binary data
Many organisations have a legal requirement to audit their activities.
Certainly mine does.
BFN, Mark.
Neil Rieck
We've purchased at least two copies of each one of Roland Hughes'
books as office resources. Sometimes we OpenVMS developers (who
usually have a little snow on the chimney) need a book like "The
Minimum You Need to Know About Service Oriented Architecture" just to
be able to translate the current world of false promises into OpenVMS
reality.
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
http://www3.sympatico.ca/n.rieck/OpenVMS.html
Richard Maher
Thanks for the reply. (Sorry for the delay)
> I noted the post on Adobe policy files.
I think the HTML5 people ignore policy-files at their peril. (Not that they
seem to care as their world is all HTTP-shaped with no end of lovely
"headers")
> [Orbited] Without some sort of access
> control it functions as an open relay - carte blanche.
I haven't used it but I believe they have some sort of white-list.
> Both are broad, evolving concepts and implementations.
Unlike TCP/IP and/or UDP Sockets with Java that have been around since year
dot. (Ok, sandboxed or signed up until now)
> FYIW; I have an (as-yet) unpublished Web application displaying
> elementary graphs of $GETRMI (monitor) data. It uses a Comet-style
> <IFRAME> and streaming long-poll. When system data changes it generates
> a <script>ed function call into browser JavaScript that supplies data
> values which the application JavaScript then graphs or displays. One
> buffered I/O of a few tens to a few hundreds of bytes (depending on what
> data have changed) per sample period. Negligible CPU ticks. Not
> full-duplex but not synchronous-poll either.
Look, polling is anathema to me but when it comes to System Stats or
RMU/SHOW STATS etc, I don't have that much of a problem with it. I mean to
try to fire off an event every time something happens on a system or a
database might generate a bit of a flood. And each users might like to set
their own "sample" (or poll) interval?
Anyway, I understand it's "How your example works" rather than "What it's
doing" that's important. Sounds interesting, I look forward to seeing it.
Though, one thing I have been curious about with Comet (and possibly your
example) is what is the server thread/process doing while it's waiting for
(say Stock Price for FMG to change or to move past some limit(s)) Is this
thread/process serving *all* clients or is there a 1:1 relationship? How is
the connection-state and context maintained between the producing-service(s)
and the consuming client? Is the thread/process unavailable for servicing
other requests while it's streaming its long-poll (or words to that effect
:-)
> If you mean, provide asynchronous (event triggered), binary (non-HTTP)
> comms using these ports then yes. Of course there is no reason why the
> services requested over these ports cannot further proxy the binary to
> TCP anything-configured. IMO the bottom line is (again) access-control.
> Whether this is the lone advantage is moot.
But I thought this is what the mail from Shannon of the WHATWG (in my
earlier post) describes as problematic? - I'm confused.
> > If Sockets can't traverse public proxy-servers with existing HTTP then
> > option 1 is no longer on the table as far as I can see?
>
> This one has lost me but I'll have a go at two of the possible intents:
>
> 1) If you mean Web Sockets can't through existing HTTP proxy then the
> answer seems to me that they are designed to do just that. Web Sockets
> behind proxy servers know it and appropriately CONNECT to tunnel.
I thought that's what Shannon was saying was problematic as they do go
through, but all roads lead to 443?
Cheers Richard Maher
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:0118206d$0$20660$c3e...@news.astraweb.com...
Mark Daniel
> Hi Mark,
>
>
>> I noted the post on Adobe policy files.
>
> I think the HTML5 people ignore policy-files at their peril. (Not that they
> seem to care as their world is all HTTP-shaped with no end of lovely
> "headers")
Cross-domain access is one of the holy grails of distributed
applications (at least those that can be mashed together from existing
webby technologies) and are always fraught with security related issues.
Of course there probably also is an element of 'HTML people' tending to
have only a hammer in their toolbox (no real slight intended).
>> [Orbited] Without some sort of access
>> control it functions as an open relay - carte blanche.
>
> I haven't used it but I believe they have some sort of white-list.
That is coarse-grained access control.
Adobe policy files are a structured, finer-grained white-list.
>> Both are broad, evolving concepts and implementations.
>
> Unlike TCP/IP and/or UDP Sockets with Java that have been around since year
> dot. (Ok, sandboxed or signed up until now)
>
>> FYIW; I have an (as-yet) unpublished Web application displaying
>> elementary graphs of $GETRMI (monitor) data. It uses a Comet-style
>> <IFRAME> and streaming long-poll. When system data changes it generates
>> a <script>ed function call into browser JavaScript that supplies data
>> values which the application JavaScript then graphs or displays. One
>> buffered I/O of a few tens to a few hundreds of bytes (depending on what
>> data have changed) per sample period. Negligible CPU ticks. Not
>> full-duplex but not synchronous-poll either.
>
> Look, polling is anathema to me but when it comes to System Stats or
> RMU/SHOW STATS etc, I don't have that much of a problem with it. I mean to
> try to fire off an event every time something happens on a system or a
> database might generate a bit of a flood. And each users might like to set
> their own "sample" (or poll) interval?
>
> Anyway, I understand it's "How your example works" rather than "What it's
> doing" that's important. Sounds interesting, I look forward to seeing it.
To better convey that this example has some level of sophistication here
is a (short-lived) peek at the HMI
http://wasd.vsm.com.au/wasd_tmp/mondesi_081116a.png
The bar graph is the instantaneous value (at a selected sample period of
2 seconds). The line graph displays the history over the last five
minutes. It's all HTML (via DOM) and JavaScript. The graphed 'events'
(changes in RMI data) are individually and asynchronously provided from
the server to the client over a persistent (long-lived) connection and
each respective graphical element is equally asynchronously updated.
It's not classic polling as you might generally describe it. Historical
data are stored in the browser. I did a couple of compiles to generate
a more interesting image.
The application is really just an exercise in Comety stuff and what can
be done with dynamic applications in a standard browser (though perhaps
with some potential usefulness).
> Though, one thing I have been curious about with Comet (and possibly your
> example) is what is the server thread/process doing while it's waiting for
> (say Stock Price for FMG to change or to move past some limit(s))
It can be doing anything it is capable of; hibernating usually, waiting
for some event such as a timer (i.e. sleeping) but of course it could
'register' for any event the implementation environment provides and use
that to provide data.
In the above application's case, when it wakes it does a $GETRMI and a
$GETSYI, and then IPCs changed data to the client, before hibernating
again. CPU hardly 'ticks' at all. One (or none) buffered I/O.
> Is this
> thread/process serving *all* clients or is there a 1:1 relationship?
In all general purpose Web serving there is such a relationship. This
is definitely the case in the above application which is written as a
CGI script. All VMS Web servers would activate an instance for each
client (in fact for a CGI script, all servers period). Of course in
many Web environments there would be nothing preventing the design and
implementation of something (like an Apache module) which maintained a
single, internal 'application' that serviced multiple, concurrent clients.
> How is
> the connection-state and context maintained between the producing-service(s)
> and the consuming client?
This is probably a non-question for such an elementary application.
However, in the above case, the browser connects to the server; the
server then activates the application and provides IPC from it back to
the client browser. The network connection persists as long as
maintained by the client and/or server and/or network. If and when the
connection is dropped the browser (notified via a DOM event) re-requests
data from the server (not requiring a page refresh, this is transparent
to the user). State and context are implicit. Data are timestamped by
the application, IPCed to the browser, placed in an time-ordered buffer
maintained by the browser, which then plots each against the time (X)
axis with every new datum. Stale data are removed from the 'older end'
of the buffer.
> Is the thread/process unavailable for servicing
> other requests while it's streaming its long-poll (or words to that effect
> :-)
Yes.
>> If you mean, provide asynchronous (event triggered), binary (non-HTTP)
>> comms using these ports then yes. Of course there is no reason why the
>> services requested over these ports cannot further proxy the binary to
>> TCP anything-configured. IMO the bottom line is (again) access-control.
>> Whether this is the lone advantage is moot.
>
> But I thought this is what the mail from Shannon of the WHATWG (in my
> earlier post) describes as problematic? - I'm confused.
My explanation was a bit thin. What I intended to describe was a Web
Socket 'service' (implement it how you like, might be as simple as a
script) under control of the origin server that then connected the Web
Socket 'request' directly using raw IP socket(s) to whatever the access
control allowed. It could also do the necessary data encoding changes
between the Web Socket protocol and the raw end-point.
This of course is NOT what you are looking for; direct
browser-to-raw-IP-endpoint. However it can (I'm guessing because I
obviously haven't tried it) emulate (perhaps 'tunnel' might be better)
asynchronous, raw network streams via a Web Socket server / raw IP
network proxy. At the risk of becoming (more) repetitive, carte blanche
access is game-over.
>>> If Sockets can't traverse public proxy-servers with existing HTTP then
>>> option 1 is no longer on the table as far as I can see?
>> This one has lost me but I'll have a go at two of the possible intents:
>>
>> 1) If you mean Web Sockets can't through existing HTTP proxy then the
>> answer seems to me that they are designed to do just that. Web Sockets
>> behind proxy servers know it and appropriately CONNECT to tunnel.
>
> I thought that's what Shannon was saying was problematic as they do go
> through, but all roads lead to 443?
I did begin that response with a disclaimer
It appears this was prudent ;-)
An interesting and opportune thread, Mark.
Richard Maher
(Once again, sorry for the delay)
> Cross-domain access is one of the holy grails of distributed
> applications
There is also a strong argument for server-side aggregation, or portal
functionality. (and good 'ol same-origin policy)
> (at least those that can be mashed together from existing
> webby technologies)
Granted.
> and are always fraught with security related issues.
To say the least. The JSON script-injection option I find particularly
scary! (Although I cannot see why, at least for Sockets, some/many people
still pursue HTTP Access Control at the expense of policy files.)
> Of course there probably also is an element of 'HTML people' tending to
> have only a hammer in their toolbox (no real slight intended).
I think you're right.
> To better convey that this example has some level of sophistication here
> is a (short-lived) peek at the HMI
>
> http://wasd.vsm.com.au/wasd_tmp/mondesi_081116a.png
Looks good! (Although I think I recall some of JFP's Stills looking sexier;
and with stock standard Ajax?)
> > Is this
> > thread/process serving *all* clients or is there a 1:1 relationship?
>
> In all general purpose Web serving there is such a relationship. This
> is definitely the case in the above application which is written as a
> CGI script. All VMS Web servers would activate an instance for each
> client (in fact for a CGI script, all servers period).
So even when you're doing traditional request/response processing, you still
get one instance per client? It's worse than I thought! But then I also
thought that "Fast"-CGI (or some such beast) was meant to overcome this
absolute bollocks? Although, limited in its application to long-polling I
imagine.
Not to worry, an article has just appeared over at CometDaily that says
there's nothing wrong with 1000 threads for 1000 users! Doesn't say anything
about attaching to the database 1000 times, duplicating memory and
everything else 1000x, paging in/out, but then that's the Comet people for
ya.
> Of course in
> many Web environments there would be nothing preventing the design and
> implementation of something (like an Apache module) which maintained a
> single, internal 'application' that serviced multiple, concurrent clients.
OK, something like a single-threaded Apache (or Tomcat?) module that took
standard Ajax/http requests, kept the connections open, sampled GETRMI data,
and streamed it back to the client(s)? Perhaps you have one you prepared
earlier?
But surely one process or thread is a bottleneck and you'd need an
application-configurable pool of Execution Server processes/threads to
allocate the work to, and that pool could grow/shrink (within parameters set
by the System Manager) to meet workload requirements? Then you might also
want to know the VMS Username of the client you're performing work for so
you can perform auditing and security checking? (It's a shame Ian Mugabe
vetoed Rdb's introduction of SQL> Set Session Authorization Persona
:ws_integer; But then Rdb doesn't work with threads so you're probably
stuffed anyway.)
This is all sounding strangely familiar for some reason. . .oh I've got it -
"You need Tier3!" As in :-
http://manson.vistech.net/t3$examples/demo_client_flex.html
Username: TIER3_DEMO
Password: QUEUE
No bollocks HTTP, SOAP, XML (unless you really want), Java, Garbage
Collector, RMI, Threads, WSIT, Axis2, Apache, Tomcat, WASD, OSU, CGI, Perl,
PHP, Pyhthon!
Just the VMS 3GLs you know and love, Oracle (Rdb or Orrible), and RMS on the
back-end. (The world's your oyster on the front-end: - HTML, Javascript,
Java, Flex, Flash, Silverlight, VMS)
> > Is the thread/process unavailable for servicing
> > other requests while it's streaming its long-poll (or words to that
effect
> > :-)
>
> Yes.
Sounds optimal :-)
> An interesting .
I agree; so that's all two of us then :-(
> and opportune thread,
How so?
Anyway, for anyone else out there who may be reading, let me reiterate an
alternative architecture for asynchronous client event notification; it's
called "UDP"! (Plus or minus Broadcasting and Multicasting functionality
depending on the network intra/internet etc) A single client socket can
receive messages from any number of server processes who in turn could be
sending message events to any number of clients. Use this in combo with a
middleware backbone based on a reliable transport such as TCP/IP and all of
your application architecture needs will have been met!
See below for a PUSH technology example (in case you missed a much earlier
post to COV)
Cheers Richard Maher
====================================
If you'd like to see an example of a bog-standard VMS server that sends UDP
messages to Web-client subscribers, then please follow these instructions: -
1) Click on the following link and read the instructions:
http://manson.vistech.net/~tier3/tier3pager.html
2) Telnet to manson.vistech.net. (If you don't already have an account on
the Deathrow cluster then please use Username: DEMO Password: USER) and
then:
$set term/width=132
$run sys$users:[users.tier3.web]demo_udp_msg
3) Enter the IP address of your client node. Your "stock-monitor" from step
1 should now spring into life with ransom stock-prices generated at 2sec
intervals. (NATed clients will find this bit problematic :-)
4) Enter any adhoc messages that you wish to appear in the seperate Java
Frame on the client.
OPCOM messages to web-subscribers? CHAT conferences? Stock-Watching? Alarm
Monitoring? - I mean what's it all about?
Cheers Richard Maher
PS. The code for Tier3Pager.java aqnd DEMO_UDP_MSG.COB are below, but all
can be found at SYS$USERS:[USERS.TIER3.WEB]
Tier3Pager.java
===========
/**
* Copyight Tier3 Software. All rights reserved.
*
* Author: Richard Maher
*
**/
import java.applet.Applet;
import java.awt.*;
import java.net.*;
import java.io.IOException;
import netscape.javascript.JSObject;
import netscape.javascript.JSException;
public class Tier3Pager extends Applet
{
private String hostName;
private JSObject browser;
private static MessageThread socketThread;
private static Tier3Talk chat;
public class MessageThread extends Thread
{
private DatagramSocket socket;
private DatagramPacket packet;
private String threadData;
public MessageThread(String name, String txt) throws Exception
{
super(name);
byte[] buffer;
threadData = txt;
String port = getParameter("PORT");
String maxBuf = getParameter("MAXBUF");
try
{
if (port == null)
socket = new DatagramSocket();
else
socket = new DatagramSocket(Integer.parseInt(port));
if (maxBuf == null)
buffer = new byte[512];
else
buffer = new byte[Integer.parseInt(maxBuf)];
packet = new DatagramPacket(buffer, buffer.length);
}
catch (Exception e)
{
e.printStackTrace();
System.out.println("Unable to create UDP Socket");
throw new Exception("Message thread could not be created");
}
setDaemon(true);
start();
}
public void shutdown()
{
socket.close();
}
public int getLocalPort()
{
return socket.getLocalPort();
}
public void run()
{
System.out.println("Started Message thread. ThreadData = " +
threadData);
String args[] = {"Started Message Thread " + threadData};
browser.call("alert", args);
boolean stopThread = false;
readLoop:
while (!stopThread)
{
try
{
socket.receive(packet);
String received = new String(packet.getData(), 0,
packet.getLength());
processMessage(received);
}
catch (SocketException e)
{
System.out.println("Shutting up shop");
stopThread = true;
continue readLoop;
}
catch (IOException e)
{
e.printStackTrace();
System.out.println("Unable to retrieve UDP message");
}
}
System.out.println("Thread run() unit terminating");
}
public void processMessage(String msgText)
{
int msgType = Integer.parseInt(msgText.substring(0,2));
switch (msgType){
case 1:
chat.append(msgText.substring(2));
break;
case 2:
String args[] = {msgText.substring(2)};
try {browser.call("priceUpdate", args);}
catch (JSException e)
{
System.out.println("Error when calling JS
priceUpdate()");
}
break;
default:
System.out.println("Unknown rec type
"+msgText);
}
}
}
public void init()
{
System.out.println("Initializing. . .");
hostName = getCodeBase().getHost();
chat = new Tier3Talk("Tier3 Messages");
requestFocus();
browser = JSObject.getWindow(this);
if (socketThread == null)
{
try
{
socketThread = new MessageThread("MsgDaemon", "SomeData");
}
catch (Exception e)
{
e.printStackTrace();
System.out.println("Could not init Tier3Pager");
}
}
}
public void alert(String alertText)
{
String args[] = {alertText};
browser.call("alert", args);
}
public void destroy()
{
if (chat != null)
chat.dispose();
boolean stillDying;
if (socketThread != null){
socketThread.shutdown();
do
{
stillDying = false;
System.out.println("Joining MessageThread");
try {socketThread.join();}
catch (InterruptedException e){
System.out.println("Interrupted Join");
stillDying = true;
}
} while (stillDying);
socketThread = null;
}
System.out.println("Tier3Pager Applet Rundown complete");
super.destroy();
}
}
DEMO_UDP_MSG.COB
====================
****************************************************************************
********
*
*
* COPYRIGHT (c) BY TIER3 SOFTWARE LTD. ALL RIGHTS RESERVED.
*
*
*
* THIS SOFTWARE IS FURNISHED UNDER A LICENSE AND MAY BE USED AND COPIED
ONLY *
* IN ACCORDANCE WITH THE TERMS AND CONDITIONS OF SUCH LICENSE AND WITH
THE *
* THE INCLUSION OF THE ABOVE COPYRIGHT NOTICE. THIS SOFTWARE OR ANY
OTHER *
* COPIES THEREOF MAY NOT BE PROVIDED OR OTHERWISE MADE AVAILABLE TO
ANY *
* OTHER PERSON. NO TITLE TO AND OWNERSHIP OF THE SOFTWARE IS
HEREBY *
* TRANSFERRED.
*
*
*
* THE INFORMATION IN THIS SOFTWARE IS SUBJECT TO CHANGE WITHOUT NOTICE
AND *
* SHOULD NOT BE CONSTRUED AS A COMMITMENT BY TIER3 SOFTWARE LTD.
*
*
*
****************************************************************************
********
*+
* Facilility: DEMO_UDP_MSG
*
* Abstract: Send a UDP message to a Java Applet Web client
*
* Build example:
* $COBOL/LIST DEMO_UDP_MSG
* $MACRO/LIST DEMO_TCP_IP_DEF
* $LINK DEMO_UDP_MSG, DEMO_TCP_IP_DEF
* $RUN DEMO_UDP_MSG
*-
identification division.
program-id. demo_udp_msg.
data division.
working-storage section.
01 stock_ticker pic s9(9) comp value external
stock_ticker.
01 acp_gethostbyname pic s9(9) comp value external
acp_gethostbyname.
01 io$_setmode pic s9(9) comp value external
io$_setmode.
01 io$_writevblk pic s9(9) comp value external
io$_writevblk.
01 io$_acpcontrol pic s9(9) comp value external
io$_acpcontrol.
01 ss$_bufferovf pic s9(9) comp value external
ss$_bufferovf.
01 ss$_endoffile pic s9(9) comp value external
ss$_endoffile.
01 ss$_abort pic s9(9) comp value external
ss$_abort.
01 ss$_normal pic s9(9) comp value external
ss$_normal.
01 sys_status pic s9(9) comp.
*
01 iosb.
03 cond_val pic s9(4) comp.
03 byte_count pic s9(4) comp.
03 pic s9(9) comp.
*
01 create_socket.
03 pic s9(4) comp value external
ucx$c_udp.
03 pic s9(4) comp value external
inet_protyp$c_dgram.
*
01 local_sock_desc.
03 pic s9(9) comp value 16.
03 pointer value
reference local_addr.
01 local_addr.
03 pic s9(4) comp value external
ucx$c_af_inet.
03 local_port_number.
05 low_byte pic x value
low-values.
05 high_byte pic x value
low-values.
03 pic s9(9) comp value external
ucx$c_inaddr_any.
03 pic x(8).
*
01 ast_area.
03 net_chan pic s9(4) comp.
03 stock_delta_secs pic s9(11)v9(7) comp value -2.
03 seed pic 9(9) comp.
03 ast_iosb.
05 ast_cond pic s9(4) comp.
05 pic x(6).
03 rem_sock_desc.
05 pic s9(9) comp value 16.
05 pointer value
reference rem_addr.
*+
* Use port number 1234 for example's sake
*-
01 rem_addr.
03 pic s9(4) comp value external
ucx$c_af_inet.
03 rem_port_number.
05 low_byte pic x value x"04".
05 high_byte pic x value x"D2".
03 rem_node_addr pic x(4).
03 pic x(8).
*
01 in_addr_name pic x(60).
01 in_addr_name_len pic 9(4) comp.
01 out_len pic 9(4) comp.
*
01 message_buffer.
03 message_type pic x(2) value "01".
03 message_text pic x(30).
*
01 user_exit pic x value "N".
01 end_key pic x(4).
01 in_time pic 9(8).
*
procedure division.
kick_off section.
00.
accept in_time from time.
move in_time to seed.
display "Enter Client's IP address or name: " erase screen no advancing.
accept in_addr_name protected reversed at end go to fini.
if in_addr_name = spaces go to fini.
perform get_udp_socket.
if sys_status not = ss$_normal go to fini.
move "Stock Ticker is now on-line" to message_text.
perform send_message.
call "sys$dclast"
using by value stock_ticker
by reference ast_area
by value 0
giving sys_status.
if sys_status not = ss$_normal go to fini.
perform get_user_message until user_exit = "Y" or sys_status not =
ss$_normal.
if sys_status not = ss$_normal go to fini.
perform socket_close.
*
fini.
call "sys$exit" using by value sys_status.
*
get_user_message section.
00.
display "Enter message text (ctrl/z = exit): " no advancing.
accept message_text reversed
bold
protected
default is space
at end move "Y" to user_exit
go to fini.
perform send_message.
*
fini.
*
send_message section.
00.
*+
* Call my Applet.
*-
call "sys$qiow"
using by value 0, net_chan, io$_writevblk
by reference iosb
by value 0, 0
by reference message_buffer
by value 32
by reference rem_sock_desc
by value 0, 0, 0
giving sys_status.
if sys_status = ss$_normal move cond_val to sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
*
get_udp_socket section.
00.
call "sys$assign"
using by descriptor "_BG:"
by reference net_chan
by value 0, 0, 0
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
*
call "str$trim"
using by descriptor in_addr_name, in_addr_name
by reference in_addr_name_len
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
call "sys$qiow"
using by value 0, net_chan, io$_acpcontrol
by reference iosb
by value 0, 0
by descriptor acp_gethostbyname,
in_addr_name(1:in_addr_name_len)
by reference out_len
by descriptor rem_node_addr
by value 0, 0
giving sys_status.
if sys_status = ss$_normal move cond_val to sys_status.
*
evaluate sys_status
when ss$_endoffile display "Unknown node"
when other continue
end-evaluate.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
call "sys$qiow"
using by value 0, net_chan, io$_setmode
by reference iosb
by value 0, 0
by reference create_socket, omitted, local_sock_desc
by value 0, 0, 0
giving sys_status.
if sys_status = ss$_normal move cond_val to sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
*
socket_close section.
00.
call "sys$dassgn" using by value net_chan giving sys_status.
*
end program demo_udp_msg.
identification division.
program-id. stock_ticker.
data division.
working-storage section.
01 stock_ast pic s9(9) comp value external
stock_ast.
01 io$_writevblk pic s9(9) comp value external
io$_writevblk.
01 ss$_normal pic s9(9) comp value external
ss$_normal.
01 sys_status pic s9(9) comp.
*
01 random_num comp-1.
01 stock_message.
03 pic x(2) value "02".
03 stock_price pic zz9.99.
*
linkage section.
*
01 ast_area.
03 net_chan pic s9(4) comp.
03 stock_delta_secs pic s9(11)v9(7) comp.
03 seed pic 9(9) comp.
03 ast_iosb.
05 ast_cond pic s9(4) comp.
05 pic x(6).
03 rem_sock_desc.
05 pic s9(9) comp.
05 pointer.
*
procedure division using ast_area.
00.
call "mth$random" using seed giving random_num.
multiply random_num by 100 giving stock_price.
call "sys$qio"
using by value 0, net_chan, io$_writevblk
by reference ast_iosb
by value stock_ast
by reference ast_area, stock_message
by value 8
by reference rem_sock_desc
by value 0, 0, 0
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
exit program.
*
end program stock_ticker.
identification division.
program-id. stock_ast.
data division.
working-storage section.
01 stock_ticker pic s9(9) comp value external
stock_ticker.
01 ss$_normal pic s9(9) comp value external
ss$_normal.
01 sys_status pic s9(9) comp.
*
linkage section.
01 ast_area.
03 net_chan pic s9(4) comp.
03 stock_delta_secs pic s9(11)v9(7) comp.
03 seed pic 9(9) comp.
03 ast_iosb.
05 ast_cond pic s9(4) comp.
05 ast_bytes pic s9(4) comp.
05 unix_cond pic s9(9) comp.
03 rem_sock_desc.
05 pic s9(9) comp.
05 pointer.
*+
procedure division using ast_area.
00.
if ast_cond not = ss$_normal call "lib$stop" using by value sys_status.
call "sys$setimr"
using by value 0
by reference stock_delta_secs
by value stock_ticker
by reference ast_area
by value 0
giving sys_status.
if sys_status not = ss$_normal call "lib$stop" using by value
sys_status.
exit program.
*
end program stock_ast.
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:012fb96c$0$20664$c3e...@news.astraweb.com...
Mark Daniel
> Hi Mark,
Hello again Richard.
> (Once again, sorry for the delay)
To quote Weizenbaum's Eliza Doctor, "How long have you been always
apologizing?" :-)
>> Cross-domain access is one of the holy grails of distributed
>> applications
>
> There is also a strong argument for server-side aggregation, or portal
> functionality. (and good 'ol same-origin policy)
>
>> (at least those that can be mashed together from existing
>> webby technologies)
>
> Granted.
>
>> and are always fraught with security related issues.
>
> To say the least. The JSON script-injection option I find particularly
> scary! (Although I cannot see why, at least for Sockets, some/many people
> still pursue HTTP Access Control at the expense of policy files.)
All injection vulnerabilities are extraordinarily scary; I know %-{ Of
course with non-interpreted environments you only have
buffer-overflowing, trampolining ones to worry about. SQL interfaces
have presented similar issues.
>> Of course there probably also is an element of 'HTML people' tending to
>> have only a hammer in their toolbox (no real slight intended).
>
> I think you're right.
>
>> To better convey that this example has some level of sophistication here
>> is a (short-lived) peek at the HMI
>>
>> http://wasd.vsm.com.au/wasd_tmp/mondesi_081116a.png
>
> Looks good! (Although I think I recall some of JFP's Stills looking sexier;
> and with stock standard Ajax?)
As observed by Mrs Claypool, "I think the Europeans do it better."
>> > Is this
>>> thread/process serving *all* clients or is there a 1:1 relationship?
>> In all general purpose Web serving there is such a relationship. This
>> is definitely the case in the above application which is written as a
>> CGI script. All VMS Web servers would activate an instance for each
>> client (in fact for a CGI script, all servers period).
>
> So even when you're doing traditional request/response processing, you still
> get one instance per client? It's worse than I thought! But then I also
> thought that "Fast"-CGI (or some such beast) was meant to overcome this
> absolute bollocks? Although, limited in its application to long-polling I
> imagine.
'Traditional' request/response HTTP for static content on 'traditional'
Apache (say, a pre-2.0, pre-POSIX-threads build) is a one-to-one,
client-to-server-process model. WASD, using VMS' QIO-AST model, is not.
With dynamic content, say using a Python or PHP engine, Apache does
not change. WASD then assumes a per-process model too.
FastCGI is an early ('90s) technology from the now assimilated Open
Market e-commerce company, designed to ameliorate the process
instantiation costs (on U*x!) associated with CGI scripting.
CGIplus is a WASD technology for providing application/engine
persistence. Nothing to do with client concurrency. It's designed to
avoid the particularly expensive VMS process creation coupled with the
often similarly expensive and latent application instantiation (as with,
though not confined to, scripting engines such as Python, Perl, etc.)
CGIplus is intended for, and is most efficient with, repeated, short
duration requests. Using it for a long-lived request is at best
inefficient, and certainly unnecessary. Otherwise MONDESI would also
have a CGIplus mode for use under WASD.
"Absolute bollocks" is far too strident. Relative bollocks would be
closer to the mark. Value judgments are dependent on the environment
and objectives.
> Not to worry, an article has just appeared over at CometDaily that says
> there's nothing wrong with 1000 threads for 1000 users! Doesn't say anything
> about attaching to the database 1000 times, duplicating memory and
> everything else 1000x, paging in/out, but then that's the Comet people for
> ya.
Well, what works for 10 concurrent usages may work for 100 and may not
for 1,000 or 10,000. Or it may. It depends on what needs to be
accomplished.
>> Of course in
>> many Web environments there would be nothing preventing the design and
>> implementation of something (like an Apache module) which maintained a
>> single, internal 'application' that serviced multiple, concurrent clients.
>
> OK, something like a single-threaded Apache (or Tomcat?) module that took
> standard Ajax/http requests, kept the connections open, sampled GETRMI data,
> and streamed it back to the client(s)? Perhaps you have one you prepared
> earlier?
AIUI; Apache 2.n contains a POSIX threads implementation which would
natively support this. Of course many (most?) Apache sites still use
the child-process model which would negate the example advantage.
I have written code that employs POSIX threads. Anyone who has done
anything non-trivial in VMS' AST-driven environment is familiar with
many of the issues. I have never written an Apache module. No. Is the
implication that it cannot or has not be done?
> But surely one process or thread is a bottleneck and you'd need an
> application-configurable pool of Execution Server processes/threads to
> allocate the work to, and that pool could grow/shrink (within parameters set
> by the System Manager) to meet workload requirements? Then you might also
> want to know the VMS Username of the client you're performing work for so
> you can perform auditing and security checking? (It's a shame Ian Mugabe
> vetoed Rdb's introduction of SQL> Set Session Authorization Persona
> :ws_integer; But then Rdb doesn't work with threads so you're probably
> stuffed anyway.)
Of course you do not mean one 'process or thread' *per server*. If it
was it would be a more-than-obvious bottleneck.
> This is all sounding strangely familiar for some reason. . .oh I've got it -
> "You need Tier3!" As in :-
The paragraph describing Tier3's pool of flexible processing resources
also *exactly* describes WASD's CGI/CGIplus application environment - I
could not have put it more succinctly myself :-)
http://wasd.vsm.com.au/ht_root/doc/scripting/scripting_0100.html
How come? Some or all of these characteristics are more often essential
requirements for accomplishing 'real work'. Partitioning activity is
fundamental to enabling, securing and auditing application environments.
If you don't need or want to pursue it using Web technologies ...
> http://manson.vistech.net/t3$examples/demo_client_flex.html
>
> Username: TIER3_DEMO
> Password: QUEUE
>
> No bollocks HTTP, SOAP, XML (unless you really want), Java, Garbage
> Collector, RMI, Threads, WSIT, Axis2, Apache, Tomcat, WASD, OSU, CGI, Perl,
> PHP, Pyhthon!
>
> Just the VMS 3GLs you know and love, Oracle (Rdb or Orrible), and RMS on the
> back-end. (The world's your oyster on the front-end: - HTML, Javascript,
> Java, Flex, Flash, Silverlight, VMS)
Sounds like having a bob both ways :-)
>>> Is the thread/process unavailable for servicing
>>> other requests while it's streaming its long-poll (or words to that
> effect
>>> :-)
>> Yes.
>
> Sounds optimal :-)
I wouldn't agree. Perhaps you have misread the question and/or
response. "Yes - the instance is UNavailable." It could be argued this
is suboptimal. Of course this, again, depends.
>> An interesting .
>
> I agree; so that's all two of us then :-(
Cows outside Oshkosh sometime seem more topical.
Of course the more-than-casual c.o.v. audience is severely constrained
these days.
>> and opportune thread,
>
> How so?
Purely personal. My experimenting with some of these
Ajaxian/Cometish/HTML5/Web2 (choose your poison) technologies during
this (and earlier, similarly themed) threads. MONDESI (the
browser-based system monitor) is on the cusp of release. This
discussion spurred me to spend the remaining 80% of the development time
on the outstanding 20% of the work ;-)
> Anyway, for anyone else out there who may be reading, let me reiterate an
> alternative architecture for asynchronous client event notification; it's
> called "UDP"! (Plus or minus Broadcasting and Multicasting functionality
> depending on the network intra/internet etc) A single client socket can
> receive messages from any number of server processes who in turn could be
> sending message events to any number of clients. Use this in combo with a
> middleware backbone based on a reliable transport such as TCP/IP and all of
> your application architecture needs will have been met!
>
> See below for a PUSH technology example (in case you missed a much earlier
> post to COV)
>
> Cheers Richard Maher
8< snip 8< some fine code and 8< snip 8< excessive quotation 8< snip 8<
Richard Maher
> With dynamic content, say using a Python or PHP engine,
> Apache does not change. WASD then assumes a per-process model too.
Delightful.
> "Absolute bollocks" is far too strident. Relative bollocks would be
> closer to the mark.
:-)
> Well, what works for 10 concurrent usages may work for 100 and may not
> for 1,000 or 10,000. Or it may. It depends on what needs to be
> accomplished.
Yeah, I'm advising those who are happy to think along those lines, to use
Sockets on the client (As in my JAVA example, or WebSockets or a.n.other)
and just use INETd on the server and be done with it. No Middleware required
at all! If 1000 threads and 1000 attaches to the database and 1000 Stacks
can happily fall under the umbrella of "it depends" then why not bring the
1000 processes in from the rain? Think of the MUTEX savings and consurrency
boost.
> I have written code that employs POSIX threads. Anyone who has done
> anything non-trivial in VMS' AST-driven environment is familiar with
> many of the issues. I have never written an Apache module. No. Is the
> implication that it cannot or has not be done?
No, just that I think there's enough devil-in-the-detail for the issue to
require whole chapters in the book of web-implementations and certainly a
lot more than a "oh you'd just use that thing" :-)
IMO, something also worthy of a chapter is the topic of why ASTs are far
superior to the Threading model! (And much easier to implement, even though
JAVA does a wonderful job af making threads easy(er))
> The paragraph describing Tier3's pool of flexible processing resources
> also *exactly* describes WASD's CGI/CGIplus application environment - I
> could not have put it more succinctly myself :-)
>
> http://wasd.vsm.com.au/ht_root/doc/scripting/scripting_0100.html
>
> How come? Some or all of these characteristics are more often essential
> requirements for accomplishing 'real work'. Partitioning activity is
> fundamental to enabling, securing and auditing application environments.
> If you don't need or want to pursue it using Web technologies ...
Let's put an end to this gratuitous willy-waving and just agree that mine
was the far more impressive display :-)
If you insist that your chalk does *exactly* what my cheese does then I
won't argue with you, but when it comes to the issue of "flexible processing
resources" then I do concede that Tier3, WASD CGI/Plus, ACMS, Rdb SQL
Services and so on. . . do have similarities.
> > No bollocks HTTP, SOAP, XML (unless you really want), Java, Garbage
> > Collector, RMI, Threads, WSIT, Axis2, Apache, Tomcat, WASD, OSU, CGI,
Perl,
> > PHP, Pyhthon!
> >
> > Just the VMS 3GLs you know and love, Oracle (Rdb or Orrible), and RMS on
the
> > back-end. (The world's your oyster on the front-end: - HTML, Javascript,
> > Java, Flex, Flash, Silverlight, VMS)
>
> Sounds like having a bob both ways :-)
I'm just appealing to that school of thought that no says "The browser *is*
the GUI" and even "The browser *is* the computer". It's amazing what can be
achieved with these simple and powerful tools! The problem for VMS, as I see
it, is that you can pick up a really grunty Intel-based LAMP server for next
to nothing and have *all* the latest and greatest versions and security/bug
fixes delivered on-time! With VMS everything is 2-to-10 years late (if
supported at all) and the equivilant box with cost you ~100x more.
What Tier3 lets you do is *integrate* your rich herritage of VMS 3GL code,
business-rules, and data, *directly* in with your IIS or LAMP-based web
architecture! But without all of the bagage infrastructure described above
in the paragraph commencing ">> No bollocks . . .". An out-dated,
poorly-performing, unpatched, and bloody-expensive VAMP-server simply can
never compete with the ubiquitous LAMP servers or IIS. Just get over it!
VMS Management's response is not only will they continue to compete in the
xAMP space, but they're also up for a bit of biffo on the desktop browser
space :-( It's only license-payer dollars I guess; who carse? Absolute
disbelief!
> > Sounds optimal :-)
>
> I wouldn't agree. Perhaps you have misread the question and/or
> response. "Yes - the instance is UNavailable." It could be argued this
> is suboptimal. Of course this, again, depends.
Sorry, an attempt at sarcasm.
> > I agree; so that's all two of us then :-(
>
> Cows outside Oshkosh sometime seem more topical.
Been good lately for some reason.
> this (and earlier, similarly themed) threads. MONDESI (the
> browser-based system monitor) is on the cusp of release. This
> discussion spurred me to spend the remaining 80% of the development time
> on the outstanding 20% of the work ;-)
I look forward to it. (MONDESI - baseball stats? I like it!) Although I
still don't know why you just don't use Ajax and a client-based
poll-interval?
Cheers Richard Maher
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:0139408d$0$20630$c3e...@news.astraweb.com...
Mark Daniel
> Hi Mark,
>
>> Apache does not change. WASD then assumes a per-process model too.
>
> Delightful.
>
>> "Absolute bollocks" is far too strident. Relative bollocks would be
>> closer to the mark.
>
> :-)
>
>> Well, what works for 10 concurrent usages may work for 100 and may not
>> for 1,000 or 10,000. Or it may. It depends on what needs to be
>> accomplished.
>
> Yeah, I'm advising those who are happy to think along those lines, to use
> Sockets on the client (As in my JAVA example, or WebSockets or a.n.other)
> and just use INETd on the server and be done with it. No Middleware required
> at all! If 1000 threads and 1000 attaches to the database and 1000 Stacks
> can happily fall under the umbrella of "it depends" then why not bring the
> 1000 processes in from the rain? Think of the MUTEX savings and consurrency
> boost.
If there are a thousand concurrent threads of database activity, my
guess is the solution will include more than a single system running a
single multi-threaded process anyway. Of course we all use extreme
cases to illustrate specific points.
>> I have written code that employs POSIX threads. Anyone who has done
>> anything non-trivial in VMS' AST-driven environment is familiar with
>> many of the issues. I have never written an Apache module. No. Is the
>> implication that it cannot or has not be done?
>
> No, just that I think there's enough devil-in-the-detail for the issue to
> require whole chapters in the book of web-implementations and certainly a
> lot more than a "oh you'd just use that thing" :-)
More than enough! Yes.
> IMO, something also worthy of a chapter is the topic of why ASTs are far
> superior to the Threading model! (And much easier to implement, even though
> JAVA does a wonderful job af making threads easy(er))
The AST model works well. If I have a gripe it would be not having an
obvious (in the source) thread of execution. It's all discrete routines
and/or application state machines. Not the easiest for humans to follow.
>> The paragraph describing Tier3's pool of flexible processing resources
>> also *exactly* describes WASD's CGI/CGIplus application environment - I
>> could not have put it more succinctly myself :-)
>>
>> http://wasd.vsm.com.au/ht_root/doc/scripting/scripting_0100.html
>>
>> How come? Some or all of these characteristics are more often essential
>> requirements for accomplishing 'real work'. Partitioning activity is
>> fundamental to enabling, securing and auditing application environments.
>> If you don't need or want to pursue it using Web technologies ...
>
> Let's put an end to this gratuitous willy-waving and just agree that mine
> was the far more impressive display :-)
An apt enough metaphor!
> If you insist that your chalk does *exactly* what my cheese does then I
> won't argue with you, but when it comes to the issue of "flexible processing
> resources" then I do concede that Tier3, WASD CGI/Plus, ACMS, Rdb SQL
> Services and so on. . . do have similarities.
They do because they've needed to be able to do that 'real work'; at
least as it is understood in a VMS context.
To become (more) monotonous; which is better, chalk or cheese? - depends
on whether your immediate need is communication or nutrition. Of
course, most ultimately desire both.
>>> No bollocks HTTP, SOAP, XML (unless you really want), Java, Garbage
>>> Collector, RMI, Threads, WSIT, Axis2, Apache, Tomcat, WASD, OSU, CGI,
> Perl,
>>> PHP, Pyhthon!
>>>
>>> Just the VMS 3GLs you know and love, Oracle (Rdb or Orrible), and RMS on
> the
>>> back-end. (The world's your oyster on the front-end: - HTML, Javascript,
>>> Java, Flex, Flash, Silverlight, VMS)
>> Sounds like having a bob both ways :-)
>
> I'm just appealing to that school of thought that no says "The browser *is*
> the GUI" and even "The browser *is* the computer". It's amazing what can be
> achieved with these simple and powerful tools! The problem for VMS, as I see
> it, is that you can pick up a really grunty Intel-based LAMP server for next
> to nothing and have *all* the latest and greatest versions and security/bug
> fixes delivered on-time! With VMS everything is 2-to-10 years late (if
> supported at all) and the equivilant box with cost you ~100x more.
There you have it in a nutshell (also IMO).
Of course, VMS just does do some things really well. I wonder what sort
of commodity box would have supported Uni Malaga's on-line registration
environment?
http://wasd.vsm.com.au/ht_root/other/can_wasd_handle_the_load.html
http://wasd.vsm.com.au/ht_root/other/can_wasd_adapt_to_the_load.html
Two and three million requests per business day. Tens of gigabytes.
I'm sure there could be examples trotted out (!) but VMS certainly is
not a passé environment, even on an aging platform (ES40).
Of course, if you've gone to buy any SPARC boxes or blades lately you'll
understand Itanium is more than competative, even with a VMS license -
until you need to cluster it. The observation is far less convincing
with the x86 equivalent. SPARC also seems to be being abandoned by ISVs
although the platform is still capable because of Solaris and open-source.
> What Tier3 lets you do is *integrate* your rich herritage of VMS 3GL code,
> business-rules, and data, *directly* in with your IIS or LAMP-based web
> architecture! But without all of the bagage infrastructure described above
> in the paragraph commencing ">> No bollocks . . .". An out-dated,
> poorly-performing, unpatched, and bloody-expensive VAMP-server simply can
> never compete with the ubiquitous LAMP servers or IIS. Just get over it!
I agree. 100%! I'm hoping I've not given the impression that I am
critical of the Tier3 model - not wishing to re-explore those spooky
sexual undertones you once claimed to have detected in communications
with one Robert Ceculski :-) However, at the risk ...
If your target client base is the great unwashed of the Internet then
you necessarily cater to the minimum common denominator - the browser.
If a more homogeneous bunch - say the staff of a company using the
mandated SOE - then why not use a designed-in component of that
environment; whether it's Java, or Flash, or .NET, or ...
Fill ya boots!
> VMS Management's response is not only will they continue to compete in the
> xAMP space, but they're also up for a bit of biffo on the desktop browser
> space :-( It's only license-payer dollars I guess; who carse? Absolute
> disbelief!
IMO; the middle-tier, informed, technically literate, make-it-happen
staff are not overly concerned with VMS browser availability. They
often must have a Web service, just as they often must have a file
service (CIFS, NFS), Mail service, etc. It's not *all* 3GLs! If the
tier with the purse-strings was told the more expensive platform had
neither 'modern' browser nor server the response would likely be, "What?
The platform is dead!" FWIW these are considered *the* commodity
applications. Rocks and hard places.
>>> Sounds optimal :-)
>> I wouldn't agree. Perhaps you have misread the question and/or
>> response. "Yes - the instance is UNavailable." It could be argued this
>> is suboptimal. Of course this, again, depends.
>
> Sorry, an attempt at sarcasm.
My fault; I must have overlooked the smiley!
>>> I agree; so that's all two of us then :-(
>> Cows outside Oshkosh sometime seem more topical.
>
> Been good lately for some reason.
SNR *has* been up.
>> this (and earlier, similarly themed) threads. MONDESI (the
>> browser-based system monitor) is on the cusp of release. This
>> discussion spurred me to spend the remaining 80% of the development time
>> on the outstanding 20% of the work ;-)
>
> I look forward to it. (MONDESI - baseball stats? I like it!) Although I
It's now out there:
> still don't know why you just don't use Ajax and a client-based
> poll-interval?
Ajaxian requests work well enough for asynchronous, event-driven,
end-user interaction in a served application. In part this is due to
TCP and explicit connection persistence between browser and server and
in part to pre-instantiated scripting engines and cached 'p-code'
reducing latency for such granular activity.
However, MONDESI is an application where once running the end-user 'sits
and watches'. Little interaction required. The buttons present in the
HMI interface with the JavaScript application running within the
browser. When required that JavaScript does interact with the server
using an 'Ajaxian' model (i.e. behind the currently viewed page but
without the XML, et.al.). Though in the MONDESIan case some datum will
*always* be changing, even on a quiescent system (if only the BIO).
Just more suitable for 'push' than 'poll'.
> Cheers Richard Maher
>
> "Mark Daniel" <mark....@vsm.com.au> wrote in message
> news:0139408d$0$20630$c3e...@news.astraweb.com...
8< snip 8< snip 8< snippety 8< snip 8<
Richard Maher
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:014bb4bc$0$14422$c3e...@news.astraweb.com...
> Richard Maher wrote:
> > I'm just appealing to that school of thought that no says "The browser
*is*
> > the GUI" and even "The browser *is* the computer". It's amazing what can
be
> > achieved with these simple and powerful tools! The problem for VMS, as I
see
> > it, is that you can pick up a really grunty Intel-based LAMP server for
next
> > to nothing and have *all* the latest and greatest versions and
security/bug
> > fixes delivered on-time! With VMS everything is 2-to-10 years late (if
> > supported at all) and the equivilant box with cost you ~100x more.
> There you have it in a nutshell (also IMO).
>
> Of course, VMS just does do some things really well. I wonder what sort
> of commodity box would have supported Uni Malaga's on-line registration
> environment?
>
> http://wasd.vsm.com.au/ht_root/other/can_wasd_handle_the_load.html
> http://wasd.vsm.com.au/ht_root/other/can_wasd_adapt_to_the_load.html
>
> Two and three million requests per business day. Tens of gigabytes.
> I'm sure there could be examples trotted out (!) but VMS certainly is
> not a passé environment, even on an aging platform (ES40).
Yes, WASD/VMS certainly has the runs on the board! But as you say, someone
will always come up with a Google or an Ebay or a MoreRealWorld-Cost example
of LAMP, WAMP, or IIS servers coping with extraordinary loads and with some
form of "cluster" and load-balancing.
Look, I honestly wish VMS was the Web-Server platform of choice in the
industry and that sites like the University of Malager were the norm, but it
has been my sad experience that even sites with oodles of VMS servers, and
applications, simply do not have them facing the web. For better or worse,
most of them have not even been running a web-server at all, and choose
instead to FTP (or at "best" ODBC) their VMS data over nightly to their *NIX
servers where the Apache server(s) reside :-( Let's also not forget
solutions a la Tibco Hubs, and IONA's charmingly coined
Middleware-for-Middleware.
Still, maybe my narrow experiences are not indicative of the installed-base
at large and others' experiences differ greatly? Maybe that's all gonna
change next week? More and more subdomain redirections to the VMS http
servers? Growing DMZ presence? Are there still any sites out there that
*only* have VMS servers?
> but VMS certainly is
> not a passé environment, even on an aging platform (ES40).
Once again let me state my belief that VMS is still, and for the forseeable
future, the best server platform on the planet! Like you I don't want to
appear like a stuck record, but can we all sit back for a minute and
remember that VMS was/is happily solving customer problems and running
corporations long before The Web and SOAP? These Billing, Call-Processing,
CIS, HeathCare, and Banking systems did not also just become passe (or
legacy) with the advent of the web. Clearly VMS Middle-Management sees these
customers as an anachronistic nuisance and for the last fifteen years has
done everything in their power to get rid of them; with much success :-( But
if only these loyal customers were presented with a *viable* way of
*integrating* their rich herritage of VMS-based 3GL code, business-logic,
and data, with their web-based infrastructure then they might not be in such
a hurry to abandon VMS and its revenue streams. Yet these same HP/VMS
Muppets are still forcing DECforms down customer's throats and offer
[O/J]DBC as *the* GUI option.
> I agree. 100%! I'm hoping I've not given the impression that I am
> critical of the Tier3 model
I was beginning to worry :-) Anyway, I think we all agree that there is no
*one* solution. For many, HTTP Server(s) will be a mandatory requirement for
integration, whether Vanilla-Http/JSON/XML/SOAP/REST (Perl/Python/PHP
access) and I'm glad VMS is spoiled with at least two fine examples: - WASD
for VMS-specific functionality and grunt, and Apache for the "Nah, Apache
does it like this" people. But for Pete's sake, will no one put an end to
the constant haemorrhaging of customers and revenue by allowing them to
Integrate, GUIfy and WEBify their existing *and future* 3GL apps?
Answer: No! All they get are the same HP wankers trotting out a expensive
"new" solution(s) every couple of years and muttering something about
"keeping ahead of the curve" (and "progress" :-)
After investing significant sums in HP's recommended solutions that are far
too radical and complex to be feasible, even if they didn't require
re-tooling and re-training entire development teams only to find the
technology obsoleted by HP even before the go-live date, you can understand
why customers are seeing the complete-rewrite and migration from VMS to
Windows/*nix becomes inevitable :-(
And this just in from: -
http://www.openvms.org/stories.php?story=08/12/06/7488318
>>>>>>>>>>>>>>>>>>>>>>>>>>>
For those customers who do not possess all the necessary skills inhouse, HP
are providing a range of services to support our new toolset. These services
range from kick-start workshops for those customers who are largely
self-sufficient to a complete project outsourcing service for those
customers who wish to utilize their existing resources elsewhere.
<<<<<<<<<<<<<<<<<<<<<<<<<<<
So HP/VMS have provided customers with a toolset they didn't ask for and
made it so bloody difficult to use that customers now have to buy
consultancy services to try to get anything done :-( Since time immemorial,
the one thing that HP/VMS employees have proved themselves to be good at, is
making work to HP/VMS employees. First it was the likes of EDS, then
Bangalore, and now HP/IMM. "Yes, get rid of your stupid development teams
and outsource to us - just look how well we run HP/VMS" - Disbelief! (But
more on that elsewhere. . .)
> with one Robert Ceculski :-) However, at the risk ...
Not wanting to invoke a torrent of off-topic and sometimes out-there posts,
but what did happen to Bob?
Anyway, at the time IIRC the exchange over SoyMAIL *was* pretty intense :-)
> [MONDESI] It's now out there:
>
> http://wasd.vsm.com.au/wasd/
>
Well done! Maybe some public/hobbyist VMS site might be interested in
putting it up? Does it need privileges?
One thing I am curious about (and too lazy to have to set up WASD and
download the example :-) is when the user changes something like the poll
interval, or even a STOP command, how is that communicated to the
long-polling thread/processes so that it knows to now sample every N secs or
STOP? Some sort of cookie with a PID and expiry? Does it know when the user
has moved page?
Cheers Richard Maher
Mark Daniel
8< snip 8<
> Still, maybe my narrow experiences are not indicative of the installed-base
> at large and others' experiences differ greatly? Maybe that's all gonna
> change next week? More and more subdomain redirections to the VMS http
> servers? Growing DMZ presence? Are there still any sites out there that
> *only* have VMS servers?
The days of significant monolithic shops are well-and-truly over.
It *would* be interesting to know how many VMS shops are using any of
these middlewares in anger.
>> with one Robert Ceculski :-) However, at the risk ...
>
> Not wanting to invoke a torrent of off-topic and sometimes out-there posts,
> but what did happen to Bob?
Raptured?
> Anyway, at the time IIRC the exchange over SoyMAIL *was* pretty intense :-)
I discovered S&M was not one of my fetishes.
>> [MONDESI] It's now out there:
>>
>> http://wasd.vsm.com.au/wasd/
>>
>
> Well done! Maybe some public/hobbyist VMS site might be interested in
> putting it up? Does it need privileges?
Thank you.
It's fairly innocuous; perhaps ~deathrow~?
No.
> One thing I am curious about (and too lazy to have to set up WASD and
> download the example :-) is when the user changes something like the poll
> interval, or even a STOP command, how is that communicated to the
> long-polling thread/processes so that it knows to now sample every N secs or
> STOP? Some sort of cookie with a PID and expiry? Does it know when the user
> has moved page?
The browser disconnects the TCP (by having JavaScript remove the DOM
element that held the link). The server detecting this closure shuts
the data collection application down. When the client wishes to
reestablish a new or changed interval data collection it restablishes
the data feed request (by JavaScript creating a new DOM element to
maintain the link). That is; changing the collection characteristics
requires a fresh data feed. There's no asynchronous, bidirectional
communication. Perhaps in the next major version it might be possible
to use more of the HTML5 of Gecko and MSIE8!
> Cheers Richard Maher
Mark Daniel
8< snip 8<
> at large and others' experiences differ greatly? Maybe that's all gonna
> change next week? More and more subdomain redirections to the VMS http
> servers? Growing DMZ presence? Are there still any sites out there that
> *only* have VMS servers?
The days of significant monolithic shops are well-and-truly over.
>> but VMS certainly is
It *would* be interesting to know how many VMS shops are using any of
these middlewares in anger.
>> with one Robert Ceculski :-) However, at the risk ...
>
> Not wanting to invoke a torrent of off-topic and sometimes out-there posts,
> but what did happen to Bob?
Raptured?
> Anyway, at the time IIRC the exchange over SoyMAIL *was* pretty intense :-)
I discovered S&M was not one of my fetishes.
>> [MONDESI] It's now out there:
>>
>> http://wasd.vsm.com.au/wasd/
>>
>
> Well done! Maybe some public/hobbyist VMS site might be interested in
> putting it up? Does it need privileges?
Thank you.
It's fairly innocuous; perhaps ~deathrow~?
No.
> One thing I am curious about (and too lazy to have to set up WASD and
> download the example :-) is when the user changes something like the poll
> interval, or even a STOP command, how is that communicated to the
> long-polling thread/processes so that it knows to now sample every N secs or
> STOP? Some sort of cookie with a PID and expiry? Does it know when the user
> has moved page?
The browser disconnects the TCP (by having JavaScript remove the DOM
Richard Maher
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:0150d6c5$0$23675$c3e...@news.astraweb.com...
>
> The days of significant monolithic shops are well-and-truly over.
Yeah, I haven't seen or even heard of one in a long long time!
> It *would* be interesting to know how many VMS shops are using any of
> these middlewares in anger.
Interesting indeed! But such information, and other ROI metrics, are the
sole concern of the HP/VMS Ministry of Truth and Customer Feedback. Do rest
assured that the decisions being taken are the right ones, and do not
concern yourself with who gets to hold the conch on this pathetic Lord of
the Flies remake as it is none of your damned business. Honestly, your
obsessive interest in the size of the installed-base is no concern of
theirs :-)
But when it comes to middleware, one thing I expect we can all agree on
(and certainly you with your years of web-server work) is that *no one wants
to install more software on the client!!!* Look at what Adobe does with the
Flash-Player (also see the code automatically generated by FlexBuilder), and
now JAVA Applets can be deployed just like web-start applications, and
obviously the browsers spend much of their days downloading new versions
of themselves. (Let's also give a mention to Ajax and down the road HTML5
and, if you have to, that JDBC thin-client thing)
All of these technologies designed to facilitate the loading of the current
version of your application and its infrastructure-code at run-time. Yet
HP/VMS sees nothing wrong with prohibiting the run-time discovery of clients
and having to install/upgrade software the old-fashioned way? Maybe they
know best? Then again they also see nothing wrong in perpetuating the
bollocks <65KB ACMS workspace limit, which does appear strange in 2009.
But what's happening in the rest of the world, outside the isolated little
island that is VMS? Well: -
1) SUN/JAVA/Applets have supported Sockets for many years and have recently
introduced Policy File support for cross-domain access.
2) Adobe/Flex also with long-term TCP/IP Socket support is standardizing
policy-files and looking to support UDP.
3) Microsoft/Silverlight has just introduced Socket support
4) HTML5 is looking to introduce WebSocket support natively (if they ever
stop floundering)
So here we have the formidible line-up of SUN, Adobe, Microsoft, Tier3, and
the HTML5-people, all acknowledging the very real benefits of being able to
talk to your servers via standard and unbridled binary Socket interaction,
yet the DEC/Compaq/HP illumni, cognescente, and intellectual giants, that it
has been my great misfortune to converse with over the past 12 years,
maintain "No one would ever want to do that! They'd rather use my baby of a
pet project instead". And yes ladies and gentlemen, this was all before they
proceeded to waste a decade of opportunity, and millions of dollars on
BridgeWorks [to be replaced by] the Waste of Substantial Investment in
Technology (WSIT), [to be replaced (augmented?) by] gSOAP [to be replaced
by] . . .GlassFish? . . . VMS-Clouds?
Anyway, for those of you, and blind Freddy, who can see the sense in what
SUN, Adobe, Microsoft, and Tier3 are doing, let me remind you of what
infrastructure you may be looking for on your VMS servers once you start
hitting the wall with your INETd configuration: -
- Transparent Multi-Threading and Network interaction (TCP/IP or DECnet)
- Application-Based Tuning and configuration
- Persistent Network Connection
- Unbridled, full-duplex binary stream communication
- VMS Authentication and client persona availability
- Transactional Data Integrity.
- Server-affinity and transaction-duration under application control
- Execution Server Processes re-usable on a transactional basis
- Preservation of Existing Investment (All you need to provide is a
shareable image with just 6 routines)
- No need for Java and its Garbage Collector, Apache, WASD, OSU, WSIT,
BridgeWorks, SOAP/Toolkit, Axis2, PHP, Perl, Python, CGI. Just the raw VMS
grunt you know and love with your rich herritage of 3GLs, businees rules,
and data, opened up to *any* client interface (Web-based or not).
Look, my contention has been that the most common middleware in use on VMS
is FTP and ODBC. Not necessarily out of choice, but due the historical and
woeful lack of viable *integration* options. Customers have simply been
forced to serve-up their VMS data to more usable platforms, as projects to
modernize or integrate existing VMS applications, using HP/VMS recommended
technology, commonly suffer from cost blow-out and/or catastrophic failure.
Again, I am happy to be proved wrong.
But where are the VMS Web Development Tutorials? Where are the hands-on
examples on the WEB, or TestDrive Cluster? We've had two examples on the web
for some time, you've got one ready to go, JFP also has a pearler, and I'm
just wondering what our combined budget is? Is HP/VMS really waiting for the
first dozen or so guinea-pig customers before they can work out what they
should be doing? 15 years into the web, they're still flipped over on the
beach, their wee flippers flailing maddly in the air with green-screens and
FTP :-( Go look at the Adobe or SUN websites if you want to see examples of
companies that are really trying to get you to use their products!
Having said that, I am reluctant to ask for more examples, or anything more
from HP/VMS, as I fear the work will simply be doled out to one of the many
cynical, self-serving, barrow-pushing, bastards that have, for the last 20
years, managed to hide from the real-world in the sheltered workshop that
has been HP/VMS.
> > but what did happen to Bob?
>
> Raptured?
Harsh.
>
> > Anyway, at the time IIRC the exchange over SoyMAIL *was* pretty intense
:-)
>
> I discovered S&M was not one of my fetishes.
It was unusual when the more unremunarated work you seemed to do for him,
the more he'd seek to wack you over the head.
>
> >> [MONDESI] It's now out there:
> >>
> >> http://wasd.vsm.com.au/wasd/
> >>
> >
> > Well done! Maybe some public/hobbyist VMS site might be interested in
> > putting it up? Does it need privileges?
>
> Thank you.
>
> It's fairly innocuous; perhaps ~deathrow~?
Graham Burley probably won't thank me for dobbing him in but he was
incredibly helpful to me in getting Tier3 up and running on MANSON and
ironing out several bugs in my code and Multinet. They're running WASD and
I'm sure he'd be interested if he has the available time. (But don't tell
him I told you. He thinks yours is "push" technology too :-)
Or is it already there and you're winding me up?
> The browser disconnects the TCP (by having JavaScript remove the DOM
> element that held the link).
Which DOM element? Is this the xhr.abort() method? Does that actually tell
the server something useful? Wow, there's a turn up!
> The server detecting this closure shuts
> the data collection application down.
Does it have to wait for the server("collection application") to quiesce? So
unlike your nano-second stuff, if the server was locked on a database or
looping away madly then would we just have to wait?
> When the client wishes to
> reestablish a new or changed interval data collection it restablishes
> the data feed request (by JavaScript creating a new DOM element to
> maintain the link). That is; changing the collection characteristics
> requires a fresh data feed.
There's that word "bollocks!" again. Why are people so blind to this crap?
Talk about fencing-wrire and duct-tape.
> There's no asynchronous, bidirectional
> communication. Perhaps in the next major version it might be possible
> to use more of the HTML5 of Gecko and MSIE8!
>
Well Tier3 has had this functionality for over eight years! This is achieved
by effectively suppling your remote procedure with a full-duplex pipe as
it's only parameter. While the ratio of messages received:sent for a given
transaction is often 1:1 there is no restriction on how many messages are
sent back to the client (eg: a result set) or whether the server needs to go
back to the client for additional information/messages *while retaining
server affinity and transaction context*. Add to this Tier3's implementation
of the io$m_interrupt/OOB functionality available in the underlying network
transport, and you can also deliver an unsolicited interrupt/message to your
remote procedure. Examples of Tier3's "Hot Abort" capability can be found
at: -
http://manson.vistech.net/t3$examples/demo_client_flex.html and
http://manson.vistech.net/t3$examples/demo_client_web.html
Username: TIER3_DEMO
Password: QUEUE
BTW, how do you get around the mandated or recommended RFC restrictions on
the number of Ajax socket connections that can be active at one time? Was it
two or three? Just make sure you don't have more than 2 (plus the original
http) going at once?
Cheers Richard Maher
Mark Daniel
> Hi Mark,
>
> "Mark Daniel" <mark....@vsm.com.au> wrote in message
> news:0150d6c5$0$23675$c3e...@news.astraweb.com...
>> The days of significant monolithic shops are well-and-truly over.
>
> Yeah, I haven't seen or even heard of one in a long long time!
>
>> It *would* be interesting to know how many VMS shops are using any of
>> these middlewares in anger.
8< snip 8< my springboard 8< and 8< the resultant arm-stand back
double-somersault with one and one half twists 8< snip 8<
>>> but what did happen to Bob?
8< snip 8< some puerile observations of my own 8< snip 8<
> Graham Burley probably won't thank me for dobbing him in but he was
> incredibly helpful to me in getting Tier3 up and running on MANSON and
Salt of the VMS earth.
> ironing out several bugs in my code and Multinet. They're running WASD and
> I'm sure he'd be interested if he has the available time. (But don't tell
> him I told you. He thinks yours is "push" technology too :-)
>
> Or is it already there and you're winding me up?
Graham must have seen the post, been proactive, and then was in touch
with me to inform it didn't produce the expected display, or compile, on
~deathrow~. Sigh! After some rummaging around I sent him an email
containing, in part, this:
Apparently there's $GETRMI and there's $GETRMI. More apparently
there's V7.3-1 (and presumably V7.3) $GETRMI and there's V7.3-2
(and later) $GETRMI. The earliest I had to test on was V7.3-2
which, of course, supported the development I did on V8.3. To cut
a long story short it's taken an extensive rework to get *most* of
the functionality in the recently released version to work on 7.3-1!
What doesn't is the count of interactive, batch and network processes.
I can see no way to provide this without an expensive round of
$PROCESS_SCANs and $GETJPIs. Not sure if I'll go to that trouble
just for pre-V7.3-2s. I'll put out a MonDeSi v1.0.1 shortly.
Graham suggested using sys$gl_*jobcnt and linking /SYSEXE which seems
(mostly) to do the job. Thanks. Though why in the world sys$gl_njobcnt
DOESN'T account the number of network jobs (at least on VMS V7.3-1 or
V8.3 and therefore it looks like NEVER HAS) is beyond me. Of course
there must be some explanation amenable to reason ;-)
>> The browser disconnects the TCP (by having JavaScript remove the DOM
>> element that held the link).
>
> Which DOM element? Is this the xhr.abort() method? Does that actually tell
> the server something useful? Wow, there's a turn up!
MONDESI activates the data collection stream by creating a hidden IFRAME
element and adding it using appendChild()
mdsDataIframe = document.createElement("iframe");
// MSIE(6+7) gets confused removing then adding ... with same IDs!
mdsDataIframe.setAttribute("id","node_iframe_"+mdsDataIframeCount);
mdsDataIframe.setAttribute("src",url);
mdsDataIframe.setAttribute("height",0);
mdsDataIframe.setAttribute("width",0);
mdsDataIframe.setAttribute("frameBorder",0);
mdsBody.appendChild(mdsDataIframe);
and closes it down with removeChild()
mdsBody.removeChild(mdsDataIframe);
delete mdsDataIframe;
Pretty standard stuff. The IFRAME "src" attribute is the data
collection URL and is fetched by the browser when the element is
introduced (appended) into the 'document' (application).
>> The server detecting this closure shuts
>> the data collection application down.
>
> Does it have to wait for the server("collection application") to quiesce? So
> unlike your nano-second stuff, if the server was locked on a database or
> looping away madly then would we just have to wait?
Would depend on the design. What do 'usual applications' do? Depends
entirely.
>> When the client wishes to
>> reestablish a new or changed interval data collection it restablishes
>> the data feed request (by JavaScript creating a new DOM element to
>> maintain the link). That is; changing the collection characteristics
>> requires a fresh data feed.
8< snip 8< another impressive flying forward one and one half somersault
with pike 8< snip 8<
> BTW, how do you get around the mandated or recommended RFC restrictions on
> the number of Ajax socket connections that can be active at one time? Was it
> two or three? Just make sure you don't have more than 2 (plus the original
> http) going at once
These are usually per target server constraints recommended, in part, to
minimise the inadvertent flooding of servers by clients. RFC 2616
'SHOULD's a maximum of two.
Firefox on FreeBSD shows:
network.http.max-connections;30
network.http.max-connections-per-server;15
network.http.max-persistent-connections-per-proxy;8
network.http.max-persistent-connections-per-server;6
SeaMonkey on VMS shows:
network.http.max-connections;24
network.http.max-connections-per-server;8
network.http.max-persistent-connections-per-proxy;4
network.http.max-persistent-connections-per-server;2
Opera on FreeBSD shows:
Max Connections Server [8]
Max connections Total [20]
AIUI; connection constraints generally are more of a performance than a
fundamental capability issue. MONDESI only ever has the single data
stream explicitly open to any given system. I have tested MONDESI
displaying six systems concurrently without issue. Connection
constraints would be more of an concern with Comety approaches rather
than short-lived Ajaxian interactions. Most Ajaxian toolkits abstract
interactions with the application server so it is only of peripheral
concern to the developer. Of course good old BSD sockets are also an
abstraction, hiding the complexities of traversing layers two and three
in the TCP/IP networking model :-)
> Cheers Richard Maher
Richard Maher
"Mark Daniel" wrote
> 8< snip 8< snip 8< snip 8< snip 8< snip 8< snip
Can't believe you snipped all the good stuff. I re-read my earlier post at
least 10 times and it just keeps getting better :-)
> Graham must have seen the post, been proactive,
He's good like that.
> Apparently there's $GETRMI and there's $GETRMI. More apparently
> there's V7.3-1 (and presumably V7.3) $GETRMI and there's V7.3-2
> (and later) $GETRMI. The earliest I had to test on was V7.3-2
> which, of course, supported the development I did on V8.3.
He still hasn't upgraded? It's incredible how slack these deathrow guys are
:-)
If only they worked for HP/VMS then they'd have a *lot more* free-time on
their hands for stuff like this :-(
You'd probably be pushing it up hill trying to get this on HP's TestDrive
cluster, but there were at least two other public VMS clusters on Ian
Miller's list a while back that may be running more recent versions?
> 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.
> > Does it have to wait for the server("collection application") to
quiesce? So
> > unlike your nano-second stuff, if the server was locked on a database or
> > looping away madly then would we just have to wait?
>
> Would depend on the design. What do 'usual applications' do? Depends
> 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?)
> 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 :-)
Anyway, I will look at the Javascript when it's available on Deathrow or
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?
Cheers Richard Maher
Mark Daniel
8< snip 8<
>> 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.
>>> Does it have to wait for the server("collection application") to
> quiesce? So
>>> unlike your nano-second stuff, if the server was locked on a database or
>>> looping away madly then would we just have to wait?
>> Would depend on the design. What do 'usual applications' do? Depends
>> 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/
> 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...]
Richard Maher
"Mark Daniel" <mark....@vsm.com.au> wrote in message
news:01577c42$0$20645$c3e...@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.
> 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. 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?
Anyway, the functionality in MONDESI demands much more than a quick look,
and I will flounder on. Once more, well done.
> 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!
> (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 :-) 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.
> 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?
>
> > 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 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?
> [I'm thinking this dialogue has just about run its course...]
Suite yourself, I certainly don't want to upset anyone (Not here anyway :-)
But I guess it would be more interesting and less drawn out with more than
just the two of us.
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
Mark Daniel
> Hi Mark,
>
> "Mark Daniel" <mark....@vsm.com.au> wrote in message
> news:01577c42$0$20645$c3e...@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.
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!
Jean-François Piéronne
[snip]
> Anyway, I will look at the Javascript when it's available on Deathrow or
> 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?
>
I have put online, in a mercurial repository, the source code 7 months
ago, I have also send you a private email with all the necessary
information. Take a look at http://hg.vmspython.org/
JF
Richard Maher
> 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....@vsm.com.au> wrote in message
news:015f695a$0$20615$c3e...@news.astraweb.com...
Richard Maher
Thanks for the reply!
> I have put online, in a mercurial repository, the source code 7 months
> ago, I
Having the source-code available is fantastic and will hopefully help others
break into Flex, especially served up by VMS. What I was looking for was a
web-page that I could click on and see the demo in action; do you have one
of those? IIRC what I saw before was a playback of a session that you had
recorded earlier.
> ago, I have also send you a private email with all the necessary
> information.
7 months ago or more recently? I've had a look back through my e-mails and
couldn't find it. Did you send it from a different address?
Cheers Richard Maher
"Jean-François Piéronne" <jf.pi...@laposte.net> wrote in message
news:49523776$0$16490$426a...@news.free.fr...