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

Hi Mark,

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.daniel@xxxxxxxxxx> wrote in message
news:0139408d$0$20630$c3e8da3@xxxxxxxxxxxxxxxxxxxx
Richard Maher wrote:
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<


.

Relevant Pages

  • A good man is never honoured in his own country
    ... for any VMS development shop. ... The number of vendors currently selling Web server ... Much of the development of WASD during the first couple of years took ... The primary impetus for an internal Web environment was a 1993 ...
    (comp.os.vms)
  • Shake the dust from your feet [Re: A good man is never honoured in his own country]
    ... Richard Maher wrote: ... for any VMS development shop. ... The number of vendors currently selling Web server ... Much of the development of WASD during the first couple of years took ...
    (comp.os.vms)
  • Re: WASD v9.2 Release [now overly long and probably tedious]
    ... As a matter of fact we no longer develop on a VMS platform at all. ... The number of vendors currently selling Web server packages on VMS perhaps reflects the aptitude of this assessment. ... Much of the development of WASD during the first couple of years took ...
    (comp.os.vms)
  • Re: If PL/I is the king of languages...
    ... It is a matter of branding, ... The point, I think, is that if you want to present yourself as a player in the web server market, you have to run Apache - and nobody else was porting Apache, ... I think WASD is terrific. ...
    (comp.os.vms)
  • Re: If PL/I is the king of languages...
    ... It is a matter of branding, ... web server market, you have to run Apache - and nobody else was porting Apache, ... I think WASD is terrific. ...
    (comp.os.vms)