Shopping Carts

[Fairlight]

On Fri, Oct 12, 2007 at 12:57:22PM -0400, after drawing runes in goat's
blood, Nancy Palmquist cast forth these immortal, mystical words:
> Walter Vaughan wrote:
>
> > mtauber19 at patmedia.net wrote:
> >
> >> Does anyone have a recommendation for setting up a shopping cart on
> >> the web using filepro cgi as the database?

Yup.  Have your wallet ready, or be ready to sink some serious time into
developing it yourself.  It's not going to be trivial to do correctly.
That's not a scare tactic, that's a flat-out reality.

> > For example if you use OSCommerce or one of it's derivatives, they
> > typically store the information in MySQL. You will then have to write
> > exports from MySQL into a format that can be imported into filePro. All
> > of this is going to be custom work.

Concur.  And the reason it'll be custom is because there's not been a
market for a shopping cart with fP hooks, so nobody's written one.  I
thought about it.  But I decided based on the lack of market demand for me
to write the storage module for FairPay (my PayPal->datastore IPN package)
for filePro, that there was no way in hell it was a sane decision to sink
10x that development time into a full-blown shopping cart.  Not given the
market share fP has.  It was something I considered and wrote off as likely
to be a horrible (possibly zero) ROI.  I was arguably the most likely
person I know in the fP community to bother to write such a creature, and I
passed on it.  What's that say?

> > While it can be done, filePro CGI is not probably the best tool to
> > accomplish what you want to do.

Concur ^ 128.  If you're going to do it, use OneGate as the bridgeware.

> If you right about the MySQL stuff, then the odbc version of filePro
> could get/put data into those files.  So you could send info to filePro
> and process stuff using filepro.  You could also return data to the SQL
> data and back to the brower.
>
> Now the fpCGI part is not relevant to this interaction.  All fpCGI (or
> any CGI program used in this way) does is collect the data submitted
> via the browser and passes it somehow to an executed program (let's say
> filePro).  It really has nothing to do with the interaction except to
> provide some security and execute an appropriate process with all the
> background information necessary (config files, environment variables,
> stuff like that.)

Where do you think the data is coming -from-?  No, the CGI portion doesn't
(necessarily) directly handle any fP<->SQL communication, nor does it
directly handle any card/merchant processing.  But the shopping cart data
itself has to come from the browser in the first place.  I fail to see
how CGI is wholly irrelevant.  Unless you're specifically limiting its
relevance within the context of fP<->SQL, in which case it may or may not
be irrelevant depending on the design model and the desired realtime nature
of the processing.

> I do add that I have used onegate and fpCGI for this middle option and
> both work well.  They do handle things differently and have advantages
> over the other depending on how they will be used.  (Cost about the
> same.)

They don't appear to support all their supported fP platforms:

Quoted from:  http://www.fptech.com/Products/Docs/fpcgisht.pdf

"fPcgi version are available for Windows. [95/98, NT], SCO Openserver.,
Unixware.,  Linux, Sun Solaris,. IBM eServer iSeries, and now FreeBSD"

Note the apparent lack of AIX support.  They also don't claim to support
Windows 2003 Server, XP, or 2000 (unless they're counting the NT base of
those as NT support, which is possible).  

OneGate, meanwhile, runs on any web server that supports CGI and has perl
installed.  I haven't -tested- Vista, but I don't foresee any issues.  I
also don't charge for cross-platform migrations if you happen to switch
your OS. http://onegate.fairlite.com/

I'd also hesitate (other concerns aside) to put a shopping system on fpcgi,
strictly because of the way it handles user count.  Or rather, doesn't.
When your fP license is used up, you're done--immediate error page.  You
don't want to generate even a custom error page telling someone you're too
busy to take their money right now, please try later--unless you actually
-have- to.  OneGate's retry facility makes this far less likely to occur.
Even if the transaction takes slightly longer, it's more likely to go
through the first time on a busy site, especially if your license count is
tight for the traffic seen.

All that aside, the CGI interfacing is only going to be a portion of the
project.  All the custom code you'll have to throw under -any- engine makes
this a pretty pricey project to even contemplate.  I personally wouldn't
estimate under five digits for it to be done correctly and comprehensively.
I'd also allow 4-6 months for implementation.  Rule of thumb for the last
13 years has said don't expect to go into production with eCommerce sites
for six months if you're starting from scratch.

Bests,

mark->