Hosting filePro applications

[Fairlight]

Simon--er, no...it was Lerebours, Jose--said:
> 
> Of course, there is the concern of fudiciality and hoping that fpTech 
> employees will not make out like bandits with our code   8-)

There's the bigger concern that $PFDATA and $PFDIR can be reset, and anyone
can get at anyone else's code.  There's no user account security level
system in play as there is with an *SQL database.  It's not -immediately-
designed for it.  This leaves two options:

1) Give everyone their own virtual machine with a copy of fP, in which case
they would try and knock you up for the license, probably.

2) Code in a user access security level system so that it does work.

Now, keep in mind that I -like- the -idea- of this.  However, in practise,
this is not a trivial offering.  They would likely lose a bit of money in
the process of implementing it.  By "lose" I mean "hemmorhage", and by
"bit" I mean "wad".

a) You'd really want, if not a data center environment, at least decent
connectivity--full T1 or better.  No idea what they have right now, but
considering their mail server read mail.henschen.com for a day when they
changed it, I think they took it all internal to Bud's place when they
closed the Indy office.  Is he set up for doing this?

b) Backup liability.  This could be more legal exposure than they'd want.
IANAL, but the key rule in software crippling has been to NEVER touch the
customer data, as it's illegal to make someone's own data unavailable
to them.  If proper dilligence is not taken to ensure good backups, or
there's just an accident, the first time someone loses even 20 important,
high-ticket orders and hauls off and sues them, fP-Tech would be getting
the shaft.  Even if they're totally innocent and it's covered under an
EULA, the cost of defending themselves from someone who's -really- ticked
about losing a $10k+ order isn't going to be pretty.

c) System security.  Let's face it, filePro has gone as late as 5.0.14
with a broken umask that leaves export files as 0666.  I wouldn't -trust-
a company to provide decent system security when their one small subsystem
program suite doesn't even have proper security.  (Was this even -fixed- in
5.6?  Anyone on the beta list want to check?  I'd do it myself if I knew a
quick way to test an export, and I just plain cannot bang out fP code as
fast as you guys.  Last export I did was in 1993.  Bit short on time to
test this.  But if it hasn't been fixed, 5.6 should not be walking out the
door until it is, IMHO.  I get sick of having to flag export files during
security audits.)

d) CPU hogging.  If you leave fP on linux at the "select file" screen (or
any other of that kind), someone uses waitkey, etc., and you're timesharing
a system, that's potentially a nightmare wherein those polling loops eat
CPU in realtime.  Get enough activity of -any- sort, and one person can
monopolise system resources, not letting others get what they paid for.
There are (what I consider bugs, like that polling loop) issues in fP
that don't lend themselves towards a friendly multi-company shared system
because they can exacerbate this problem.  ONE person was developing
CGI with filePro the other week on their own system and stranded six
dreport processes without knowing about it--all waiting for someone to hit
enter on a double-declared GLOBAL, which of course will never happen in
a CGI environment.  They were all in polling loops and all eating CPU in
realtime.  When I killed them, it took the system from a load of 5+ to a
load of 0.  I don't know how they didn't notice--I could "feel" it when I
logged in.  "Sluggish...like a wet sponge."  --Airplane!

These are only the initial problems I see with such a system.  I'm sure if
I put more time into it, there are more.

I like the idea Jose, but the practicality is something else entirely.

mark->