filePro, PHP, CSS, JavaScript, Ajax and HTML5

[Fairlight]

With neither thought nor caution, Jose Lerebours blurted:
> Am I crazy to think that filePro future may be better secured as a
> "database engine" in lieu of a "development tool"?

Uhm, yes, quite mad.

> With what's out there to quickly deploy applications with incredible
> ease and lots of gadgets, the "speed of development"
> known to filePro is vanishing.  I say so since the margin is so small
> and the added capabilities with other development
> tools have proven "impossible" for filePro.

fP development takes longer because it's a non-standard, non-structured
language that few people know anymore.

> I love filePro and PHP as a pair.  I have developed several
> applications where PHP acts as the front end and filePro as
> the DB Engine.  Speed of process is not worst than MySQL (at least
> when under 100K records queries but I have really
> timed this).

Speed of actual database result delivery may not differ.  Tried comparing
resource usage?  You're eating more RAM and CPU with each instance of clerk
or report running.  

> Imagine filePro as a DB engine that can be deployed with LAMP (or
> should I say LAFP) and WAMP (or WAFP).  For now,
> I wonder what you guys/gals thinks about this and some help with the
> question I posted earlier.

I think it's utterly insane.  :)  You just suggested that the -weakest-
part of fP is its possible future.  I could buy many other aspects of fP
being touted as something worth preserving.  The outdated, fixed-width,
blobs-and-memos-as-tack-ons storage engine, complete with DKNF errors
reported as recently as a week ago?  Not so much, mate.  And interfacing to
it is still an issue of extreme kludginess.

Counterrotating magnets to generate antigravity makes more sense--and that
just plain doesn't work.  :P~~~

mark->
-- 
Audio panton, cogito singularis.