fpCGI failure, part 2

[Fairlight]

Yo, homey, in case you don' be listenin', Nancy Palmquist done said:
> I do not say that onegate is not an excellent tool.  It has features not
> found in fpCGI and you are right it is structured somewhat differently,
> but in many ways the same.

There are only so many ways to do CGI.  Most of these can be boiled down
into two methods:  correctly and incorrectly.  :)

> But I found that both have the same basic flow and require the same
> tedious attention to detail.
>
> Both need the environment clearly defined, since nothing else is assumed.
>
> Both need a robust filePro process that has taken into account all crash
> issues and is running flawlessly.

That would be the nature of the CGI "environment"...the nature of the
beast, so to speak.  Short of something higher-level like CodeCharge being
built that will support fP, OG is about as good as it's going to get at
the low level.  That's really the difference--high versus low level.
And I actually have had a suggestion to write something like CodeCharge
Studio (www.codecharge.com) specifically for fP, laying it on top of OG.
It'll likely never happen from my company.  

Now STN...they're working on something that actually is a bit more like
CodeCharge, letting you design/configure (Bruce, help!) easily at the
higher level, and lays on top of OG.  And what I've seen of it is really
cool!

> In one case, we installed onegate for features unavailable in fpCGI.  Now
> the customer runs both onegate and fpCGI on the same servers.  BTW - the
> feature we needed was the ability to receive a text field - a special
> form field that would allow for free form text. fpCGI would not handle it
> properly, onegate does.

According to my internal comparison table between the two products, I have
31 advancements or features fpcgi doesn't.  You may add one if their cost
is still $1k higher for iSeries and Solaris, and you may subtract one if
they added automatic file cleanup of -all- files, which are the only two
things I haven't been able to verify recently.  Either way, say around 30.

> There were also more options for firewall setups in onegate.  It could
> allow a very narrow network of computers to interact without too much
> problem.  That has not been helpful to us, but I can see the potential in
> that.

More?  Any is more like it.  They don't have an internal application-level
firewall last time I looked.

The nice thing about it is that you can limit accounting to just certain
computers on the LAN, Inventory to others, and your public stuff to the
world at large--or even block the LAN from accessing what the world can, if
you need an inverse firewall.  But you can do it -per task-, at the
application level, without relying on URLs.

> Mark - don't get your shorts in a bunch.  You know I love Onegate, but I
> just want to be fair and offer suggestions that the customer can use to
> solve his problem.  I hate answers that go like this:
>
> Problem:  My pants are dirty.
>
> Solution: Buy new pants.

And don't think I don't hate that kind of pat answer.  But I've also been
trying to help him debug within the context of what he's working with as
well, as late as today with the redirect clarification.  I'm not unwilling
to help him get it running right on fPcgi--assuming that's possible as
fPcgi sits.

And my shorts aren't exactly in a bunch.  I was a bit rankled that you'd
say OG isn't the way to go.  It's been a proven solution to a number of
fPcgi ills--including at least one instance of programs not actually
running, as was reported to me.

As for the problem/solution comment...I'll give you my take:

>From my perspective, it's not actually just that the pants are dirty, it's
that they're dirty and torn up work jeans being used for Sunday best to
church.  There are some things you're raised to know just aren't done.

There are ways to do CGI and there are ways to not do CGI--ways that it
should never, ever be done.  OneGate is the former, fPcgi does much of
the latter.  Yes, it technically "gets the job done", just as pants cover
your legs (more or less) no matter the occasion.  But from a security
standpoint, it's a mess; I would venture that the person(s) that wrote
the initial version hadn't worked with CGI before, and really didn't know
many to most of the tenets of CGI security.  From what another developer
told me, it wasn't even intended to be a product in its own right--it spun
out of one of the projects some years back...JumpStart, I think.  They
sank whatever project, this was part of it, and someone convinced them to
release it separately because it was of use.

So yes, it lacks polish, it lacks features, the security is still a
nightmare (especially considering v2 defaults to v1's "exterior" model of
client-side commands), and it really was not designed to be used in the
role it's filling from what I've been told.  And I trust the source that
told me that.

OG, on the other hand, was designed from the ground up, with full knowledge
of CGI security practises and nine years of practical experience in
implementation before line one was written.  The URL to the original draft
whitepaper was actually posted to this list, detailing something called
UniForm, which was what OG sprang from--about 3-4 years after I wrote the
paper, and after fPcgi was released.  The reason for the delay?  I took
time to migrate from C to Perl, which instantly gave me an advantage in
terms of ease of coding that fP-Tech doesn't have because they're still
dealing with C.  You don't want to have to parse multipart/form-data in
C if you can at all help it (it's messy enough in perl and I've seen
two different libraries that do it--the memory management in C would be
hideous), which is why I suspect they never tackled file uploads, if I had
to guess.

Is it "cheating" using a library module to bootstrap?  Look up Gamebryo
sometime on Wikipedia and the list of games it has been used to develop.
:) I don't think any of those companies are embarassed.  Firaxis is just
crying all the way to the bank with "Civilization 4" profits, I'm sure.
But had I learned Perl a bit earlier, I'd have beat fPcgi out the door, and
I daresay more people wouldn't be having the problems they've had.  Alas,
it didn't work that way.  Coulda woulda shoulda.

Bottom line:  You need to get somewhere 15 miles away.  Would you rather go
on a Segway, or in a Porsche with all the trimmings?  (All but the nerdiest
nerds have gotta be saying the Porsche!)

> Obviously, wash the pants might be a more efficient solution, but we all
> know Buy New Pants could also be a solution, just not a great one.

Depends what they're stained with.  If it's blood from when you cut
yourself somehow, well that's pretty much shot right there, and then buying
new pants -is- the proper solution.  I view the deficiencies in fPcgi much
the same way--it's fundamentally (and irrevocably, given the hellbent
default backdwards-compatibility stance they take) flawed, IMNSHO.

Doesn't mean I won't help find a solution under the current constraints.
Also doesn't stop me from saying there's a better way to go though.

The whole fPcgi vs OG thing becomes moot in this context if he's moving
to a LAMP stack soon anyway.  Unless it becomes a time/money sink in the
interim trying to keep the current architecture running until the new one
is ready.  Which is why I suggested it--because this kind of thing can add
up quickly.  Apparently it hasn't yet...but it can, and has for others.
I've seen it happen, so I offered the alternative.  That's it.  Well that,
and we all gotta make a living, let's not forget that little reality.  :)

Peace,

mark->
-- 
"Moral cowardice will surely be written as the cause on the death
certificate of what used to be Western Civilization." --James P. Hogan