[Info-vax] Apache Plugins for OpenVMS?

[IanD]

Yes, perhaps in the excessive test I posted, this got missed :-)

> >>
> >> It is looked after by a Mark Daniel, who works for the ADF (Australian
> >> defense force) as WASD was developed there, so this guy is somewhat
> >> security bent on maintaining a tight ship, so to speak
> >>
> >> Mark also produces some other goodies, such as 'dclinabox' which
> >> allows you to use a web browser as a VT terminal and 'soymail', which
> >> is a web browser interface to VMS mail. He's also written websocket
> >> interfacing into WASD as well
> >>


> 
> The side belongs to Mark Daniel, not the poster you replied to. :-)
> 
> 

> 
> I do not understand here. We uses SOAP services on our Alpha built
> using the gSOAP kit from Brett, and it runs through WASD. WASD realy
> doesn't care that the client and the server process talks SOAP, it
> is just a server process just as any other CGI process.
> Where is the "show stopper"?
> 
> Then there is also a *persistent* gSOAP module for WASD. That is,
> if you have a higher load and do not want the process creation at
> each client call, you can use that. In our case that was never
> an issue, so we get a new client process each time.
> 
> We do use the persistend Python module, since that has a much
> higher initilization overhead. With the persistent module, it
> runs very well with low overhead.
> 
> Have fun! WASD works well and it also has been following the
> latest technologes for networking and security issues.
> 
> Jan-Erik.
> 

> >
> > That said, I'm going to download a copy of WASD tomorrow then install it
> > on one of the junk Alpha's in the back room. I think a good case could
> > be made for moving to WASD if CSWS stays stuck back in time.
> >

:-)

Yep, Mark Daniel is the WASD author. My association with WASD is nothing more than a once sceptic turned advocate of it

He's actually really really approachable and broods over WASD with a passion

I posted about WASD because I doubt many have heard of it before. I hadn't at one place I worked in and we wanted to put in a webserver so we evaluated a few and WASD was one of them

To my shame and lack of objectiveness, I frowned on WASD from the offset because it wasn't 'apache'

Mark came in and gave an overview of WASD and I sat there thinking 'yeah yeah yeah', yet he wasn't your typical pushy salesperson (because he's not!) and he didn't run from any hard questions asked of WASD. I started to realise as he spoke that this product was built from users requirements and adjusted over the years to suit real work sites and what people wanted from a web-server

After the first round of testing came in I very quickly pulled by head in. WASD simply out performed Apache by orders of magnitude. There was no comparison and as more workload was put upon Apache it had a quick death curve where-as WASD kept powering on with a more acceptable performance degradation

Mark is responsive, and the community is really helpful and no question is too silly to ask

Often a suggestion for improvements gets made, then a little while later Mark sends a notification email saying that 'in his spare time' he's added this little feature to WASD lol

If it's a security related issue he's all over it, he takes security very seriously. 
A long long long time back WASD had a security flaw pointed out in it. Mark instead of trying to hide it quickly produced a patch and this sent him on a mission to totally revamp WASD with security in mind from the ground up - this has produced a great package although as Mark says 'One can never take security seriously enough" :-)

The presentation in the link below was made some time back at a technical boot camp where Mark did a presentation about WASD, it's worth a look, especially around the performance slides and the large university site that runs WASD and the amount of data they push through it. Slide 51 of course is very good!, I wonder where that comment came from! ;-)

http://wasd.vsm.com.au/other/D215_WASD_Apache.ppt

It would be good if after you get WASD running, you could let the rest of us know how you found it, what problems if any you encountered. Objective feedback on how it behaves in the real world is always welcome

> We do use the persistend Python module, since that has a much
> higher initilization overhead. With the persistent module, it
> runs very well with low overhead.
> 
...
> 
> Jan-Erik.

Oh, I need some help getting my head around this, I may shoot you an email at some time for some pointers, if you don't mind :-)