OneGate and filePro (was: Re: Bulldog ODBC for filePro)

[Fairlight]

I've just gotten to this one--meant to reply to this earlier.

Is it just me, or did Jay Ashworth say:
> 
> Viz OneGate, which Mark mentioned.  I've looked at it, and it's nice
> and tight, but it's still not all that small, from what I gather (I've
> not looked at the actual code), and there's *still* a
> fairly-non-filePro'ishness to it that makes the learning curve... well,
> let's just say that *I* would have had to be fairly motivated.
> 
> No offense, Mark.

None taken.  Theere is an installer program, a program set cloner, and a
lock cleaner, as well as a menu-based config tool for helping you manage
configuration files.  The relative size of the entire suite is quite small:

[cobalt] [~/perl/projects/onegate] [11:39am]: wc install.pl onegate ogconfig ogcl* fponegate/unix/onegate/prc.ogcgixml

    239    1094   10518 install.pl
   1077    4569   45100 onegate
    867    3618   33438 ogconfig
     49     173    1603 ogclean
    201     736    7231 ogclone
     82     659    7851 fponegate/unix/onegate/prc.ogcgixml
   2515   10849  105741 total

Personally, I don't think that's large.  Even adding html2prc (now a
separate product), you only add 271 lines.  And html2prc, 130 lines (more
or less) is dedicated to finding a native pager on any platform (less, or
more if less isn't available), as well as handling --version, --changelog,
and --help.  And if 82 lines of filePro isn't light, I'm not sure what is.
It's 95% XML parser code.

As to your comments about a learning curve, OneGate is actually very easy
to learn, and I've had someone up and doing miracles inside a few days,
starting from ground zero where they didn't know the product, although
they'd tried fPcgi.  

Aside from learning how the configuration works, there's really nothing to
it.  At its basest level, you launch either *report or *clerk, lookup your
data, and write an output file any way you choose, based on the results.  I
fail to see what's complex about that.  Security features and configuration
notwithstanding, it's in essence just a large 2-way "pipe".  Data in, data
out.  Nothing horribly complex.

Now doing CGI in general, along with coding session management and the
like, is a bit more complex.  But that has nothing to do with the specific
software.  Those are methodologies you use within the scope of any given
project, but OG doesn't limit you, nor does it make it hard to manage.
That paradigm takes a -little- getting used to, but it's not complicated.
The most complicated bits are keeping your security tight throughout your
application--and I have an article that's freely available on my web site
which points out pretty much most of the major (and even minor) tenets of
CGI coding as regards security.

I'm curious to know how you've "looked at it" to the point where you think
it's a learning curve you'd have to be motivated to get past.  You haven't
purchased it, you haven't seen the source, you haven't worked with it...and
you somehow feel your opinion has some weight despite these facts.  "Don't
knock it till you try it."  If you can handle your regular python coding,
and with the administration experience you have under your belt, you'd be
up and doing things inside an hour or two, I'm pretty confident--if that
long!

Actually, while it -is- tight, I'd like to know how you've made -that-
determination as well, never having laid eyes on it directly.  If I'm
going to question how you can make a negative judgement under these
circumstances, I have to question even the positive judgement (true though
it may be) based on the same criterion.  Objectively, I don't think you can
claim anything about it one way or another unless you've at least seen it
on someone else's system, which I doubt you have.

As far as "non-filePro'ishness", I'm unsure what about LOOKUP, and either
OPEN/WRITE[LINE]/CLOSE or EXPORT is non-filePro-ish about it.  If you
mean the actual integration where you have to configure something besides
filePro processing, well that's a given, isn't it?  We -are- talking
integration work.  My own demo, the fP Room File Sharing System, is
relatively non-typical as a filePro "application", but all the filePro
code is present and available for perusal.  It's all written in plain
ol' processing and illustrates many things you'd want to do in a CGI
environment--including how to handle session management in filePro.  But it
-is- a non-typical application in terms of for what one would usually use
filePro.  Alan Mazuti has a much better filePro-centric demo that showcases
both OneGate and Bob Rasmussen's WEPO control, along with Print Wizard.
That demo is impressive, and it's far more in line with what you'd expect
from a "typical" filePro application.

Overall, I take absolutely no offense, but I also see no grounds on which
you could have made any of the statements you made with even a modicum of
veracity.  There's certainly no reason to make it seem like the adoption
curve is well nigh insurmountable.  That's by no means the case, and
I'd hate to see someone frightened off by what appear to be unfounded
"observations" made by someone that hasn't even tried the product.

mark->
-- 
Fairlight->   ||| "My mother said, 'To get things    | Fairlight Consulting
  __/\__      ||| done, you better not mess with     |
 <__<>__>     ||| Major Tom!'" --Bowie               | http://www.fairlite.com
    \/        |||                                    | info at fairlite.com