[Info-vax] You Got To Pick A Pocket Or Two Boys!

[Richard Maher]

Hi Jan-Erik,

"Richard Maher" <maher_rj at hotspamnotmail.com> wrote in message
news:h65qf2$b8g$1 at news-01.bur.connect.com.au...
> Hi Arne,
>
> "Arne Vajhøj" <arne at vajhoej.dk> wrote in message
> news:4a690785$0$48246$14726298 at news.sunsite.dk...
> > Jan-Erik Söderholm wrote:
> > > Arne Vajhøj wrote:
> > >> Using FastCGI to reduce activation overhead is not exactly new.
> > >
> > > No, it's not. But it wasn't used by the the gSOAP/VMS kit.
> > > There are examples of running as an "module" within
> > > Apache, and as far as I understand using FastCGI is
> > > quite similar to that. And I prefer WASD over the Apache
> > > port.
> >
> > FastCGI and Apache module are different but solves the same
> > problem.
> >
> > Apache modules run code in process, FastCGI is a persistent
> > separate process used for multiple requests. Both reduce
> > activation overhead.
>
> Let's hope Mark was more concerned about solving the 1:1 process/thread
per
> client conundrum in this case than he was with his long-polling
"server-push
> my arse!" paradigm. Still the system developers and architects don't seem
to
> concern themselves with such trivia so why should the users/customers
care?
> (Having said that, one has to wonder why more people simply don't use the
> lovely free INETd that's been there since year dot but, now that IPsec has
> been cancelled, I guess everyone would have to put their own outdated SSL
> wrapper around things :-( Another machiavellian master-stroke by the IMM
> team!)
>
> Still you guys are really pushing-the-envelope with this "not having to
> start a fresh process for every request" stuff! Might not be too late for
> that patent application. Best put another one in for not having to
> start/stop an image for each request either - All good stuff.
>
> I wonder if all the other OSes know how we're splitting-atoms here in
> VMS-Labs? Cut-off on our own little technological Galapagos, without
> IPsec or a Firewall capability, we are free to evolve/mutate at our own
> pace - just like Tasmania.
> >
> > >> Hm.
> > >>
> > >> Are gSOAP for VMS being done by HP ??
> > >
> > > Not up to today.
> >
> > So none of Richard VMS license money has been used so far.
>
> Yes children, it's all done in their "free-time" (God knows they've got
> enough of it!). On their own machines, with their own licenses, at their
own
> premises, with no access to a hit-list of customers to harass and spam on
> their own phones and HP letter-headed e-mails. Yes you should see their
> weekly HP timesheets - no doubt packed full of 40, sometimes 60, minutes
of
> billable work.
>
> Jan-Erik I'm not sure who "the maintainer of gSOAP/VMS" is but, if Fagin
> ever stops bitch-slapping him long enough to answer a question, why don't
> you ask young Dodger "In what year was Tier3 first demo'd up and running
on
> Digital's premises?" I make it 1995 but my memory's not what it used to
be.
> Anyway let's recap on what we've seen come and go in that time shall we: -
>
> ONC/RPC, DCE/RPC, BridgeWorks, SOAP/Toolkit, DECAdmire, ACMSxp. And for a
> few years now the long suffering VMS customers have been told to invest in
> Axis2 and WSIT 'cos that's where HP/VMS is investing all its efforts. Yet
> here we are confronted with what appears to be HP/VMS employees
deliberately
> sinking the knife into Axis2 - What's a customer meant to think? Devil
makes
> work for idle hands I suppose. Still, if I had been reliably tipped-off
> about a genuine customer requirement 14 years ago and I then got to
witness
> pathetic alternative solutions fall by the wayside one-by-one then I might
> start to cotton-on too.
>
> Alas, imagining where Tier3 and VMS could be now in the IT world given
just
> 1% of what's been squandered by these failed projects is as painful as
> wondering how prosperous that hunch-back in Manon des Sources would've
been
> if those two poisonous bastards hadn't blocked up the spring :-(
>
> And just when you think it couldn't get any worse, you'll find no comfort
in
> the knowledge that the demonstrably incompetent fools that have been
> masquarading as VMS management for the last 15 - 20 years are not only
still
> on the payroll, they're still making the decisions :-o
>
> Why were all those VMS engineers with 20+ years of OS kernel development
> sacked again?
> >
> > >                   But as far as I understand it will be
> > > (more) officialy supported by HP/VMS soon. gSOAP is in
> > > VMS roadmap now (FWIW). This is of course an important
> > > issue for some sites/customers, included the one I'm
> > > working with.
>
> Excellent Jan-Erik! How much are they willing to pay for support? Just how
> "important" is it to them? This could be the turning point for HP/VMS;
> another Red Hat perhaps?
>
> Hold on Arne! I can't find this statement in here anywhere:  "You have so
> far not been able to show a single dollar in extra revenue by implementing
> gSOAP.". Go get him Arne - put the kybosh on Jan-Erik and his gSOAP! Go on
> show us your integrity, your honesty, and sense of balanced, fair play. .
.
>
> How about "Implementing SOAP on platform X being profitably does not imply
> implementing SOAP on platform Y being profitably."?
>
> >
> > But will now, when there are real customers wanting it.
>
> This is all gravy Arne, not only can HP/VMS reap the new income stream
from
> gSOAP customers like Jan-Eriks but just think of the costs saved by
> cancelling the presumably unwanted Axis2 and WSIT products. You guys are
> definitely onto something here!
>
> Yes indeed, how many millions of VMS license-payer dollars (including my
> USD$200/year :-) has been, again presumably, wasted on this
> "Industry-Standard Middleware"? What is it that gSOAP does that Axis2
> doesn't Arne? Is there more to this than an anti-Apache coallition?
>
> It would be inconceivable that some HP/VMS employees would set out for
years
> deliberately white-anting what are ostensibly their coleagues projects for
> no other reason than to manufacture a job for themselves - wouldn't it?
>
> And as the scorpion's tail of self-interest once again pierces as deeply
as
> ever into the side of the VMS frog, the river bank looks further and
further
> away :-(
> >
> > Arne
>
> Cheers Richard Maher
>
> PS. Is this where we all say "Take what you can! Give nothin' back!" or
> would that be a mixed-metaphor/movie too far?
>
> PPS. I see there's now PHP_SOAP available. You just can't have too many of
> these things. 4 browsers and now at least 4 SOAP implementations; "You're
in
> the money, You're in the money, You've gotta lotta what it takes to get
> along".
>

I've just found myself suggesting the Apache Axis2/C "solution" to a
prospective SOAP/VMS client here in c.o.v and I thought I'd better check
first on how well your mates in the anti-Apache "Coalition of the Unwilling"
were getting on. After all I wouldn't want to give long-suffering VMS
customers yet another bum-steer on the technology-support front. Let's face
it, if your gSOAP comrades have been successful in white-anting Apache/VMS
to its very core then who am I to stand in their way?

Having said that, I can't help wondering if VMS customers being able to draw
freely from the deep pool of LAMP/WAMP talent for their staffing
requirements could only be a good thing - what say you Jan-Erik? No longer
held to ransom by expensive, bearded, dinosaurs and their cryptic VMS
incantations, these customers can now pick up the same dime-a-doz
web-masters with portable Apache config and tuning skills that look after
their Linux servers. Good news all round for VMS customers don't you think?

Nah, best listen to the same old wankers that used to sell you down the line
on the "Enterprise Service Bus" (how's that panning out with everyone btw?)
and BridgeWorks and WSIT and SOAP/Toolkit and DECForms and whatever else
dejour is funding their lavish lifestyles :-(

Regards Richard Maher

PS. I've just been on an IIS7 WCF course and was disappointed that that
skipped over the Windows Process Activation Service (WAS) as it looks like
just another INETd remake to me - anyone else see them moving way beyond
SOAP? Then I've also been looking at Google mail APIs and how you can get
Python pluig-ins (in our case) or PHP or Java or xyz client *PLUG-INS*
regardless of the underlying Google middleware infrastructure (Even though
it's REST with nary a SOAP header in sight!)

Imagine giving your clients a simple plug-in (or JAR) downloadable from the
web on-demand with connect/authorize methods and attributes. No WSDL, no
XML, no being charged huge consultancy fees so someone can write the same
SOAP client for you that they've just written for everyone else. (But some
with SOAPExceptions and WS-Auth yet others with XML-resident errors and
credentials) Sound good?

PPS. How's Eric "swami" Newcomer getting on? (Or your IONA shares for that
matter? Maybe much of the SOA hype was built on the same stuff as the Irish
economy?)

PPPS. Is [g]SOAP to systems development what Iceland was to international
finance? It's all good until . . .