credit card processing on unix with fp

[Fairlight]

When asked his whereabouts on Wed, Nov 14, 2007 at 04:11:45PM -0500,
scooter6 at gmail.com took the fifth, drank it, and then slurred:
>    I too am looking for this - and after attending the filePro conference I
> might be convinced that
>    sockets is the way to go on this - unless there is an alternative.

The problem with this plan of action is that if the CC company (or the
bank, if you're dealing with ACH) requires SSL, you're screwed. fP has
(TTBOMK) -no- SSL library support built in.  If they have it, it hasn't
been advertised well/at all.

What you have with fP-Sockets is access to the basic socket and networking
API via fP's language.  However, that comes with NO application-level
protocols.  You get TCP [and possibly UDP] as your network protocol, that's
it.  But the app-level protocols that ride on top of TCP are entirely
non-existant in their offering.  Here's the networking layer cake:

App-Level Protocol (POP3, SMTP, NNTP, HTTP, SSL, etc.)
        |
    TCP or UDP
        |
       IP
        |
Physical medium protocol (Frame Relay, ATM, etc.)

The physical medium is handled by your OS.  So is IP.  TCP and UDP are as
well, but you get access to manipulate and use them (which inherently uses
the two layers below them) with fP-Sockets.  The top layer of the cake, the
frosting if you will, has been left off--no application-level protocols are
pre-made [barring perhaps the POP3 code Ken wrote as a proof of concept
years back].

If you want to talk POP3, SMTP, HTTP, okay, those are all fairly
straightforward to redesign.

Any financial institution worth dealing with should be mandating SSL.  In
that case, you'd essentially have to rewrite an SSL layer -and- the HTTP
layer from scratch in fP, before you could to anything at the application
level.  And SSL is -not- trivial.

Three words:  Not Cost Effective.

Actually, just one word:  Pain.

mark->