What should fp 6.0 look like?

[Jeremy Anderson]

Fairlight wrote:

> I'm more for abstracting the storage/retrieval API's, dropping the native
> storage to module form, and implementing Oracle, MySQL, PgSQL, Informix,
> DB2, and a host of other drivers.  Instantly you'd have a character-based
> RAD kit that was compatible with most of the popular database engines, yet
> had the ease and simplicity you've come to expect from filePro.  Stored
> procedures aside, those are all engines, bring your own language and
> interfaces.  Here we have a pretty darned good combination of the latter
> two, and it can't talk to anything.  Imagine being able to select a
> storage/retrival driver--or better yet, -independantly- select them in
> processing so you can talk to two things at once from the same processing
> table, one in, one out.

What I wouldn't give for the ability to suck data out, efficiently, with 
either Perl or Python.  It would make me like FP a _lot_ more, because 
then I could use two languages I understand, rather than having to learn 
the language that is FP's 4GL.  Like all 4GLs, I find it artificially 
limiting, and arcane.

> And I've looked...there doesn't appear to be a terminal-based RAD kit for
> any of the *SQL engines.  You've got several GUI solutions, some web-based
> solutions, but no terminal-based solutions.  If fP just went the route
> above, they could hit a really nice market segment, since there's a virtual
> vacuum in this area.  If they'd let go of some of the legacy issues and
> enhance things a bit (like allowing > 80x24 screens), this could be sweet.

I'd buy in a second.  This would allow me to genuinely leverage the data 
in FP, and my previous investment.  Instead, I find myself using editors 
which are not as familiar to me as vi, a language that I'm still 
learning, and a whole new set of language-limitations (since pretty much 
all languages use them).

> Kill 80x24 screen limits.

PLEEEEEEEEEEEEEEEEEEEEEEEEEEEASE.
I'm getting to the point where I'm out of acreage on a single screen.
The information is all related, and it would be easiest to display it 
all in one place, but I will no longer be able to do this, since I'm 
simply out of room.

And the ability to natively export csv.   MAN, would that save me some 
coding.
-- 
Jeremy Anderson			      jeremy (at) plunketts.net
IT Manager, Plunkett's Pest Control   Author, Multitool Linux