What should fp 6.0 look like?

[Fairlight]

>From inside the gravity well of a singularity, Walter Vaughan shouted:
> 
> Smiley duly noted. However it does bring to mind what kind of features 
> are needed for a filePro 6.0. Realistically, what else's needed?

More than they'll ever do, IMHO.  So much of what I'd do would require
tossing bits of legacy this and legacy that.  They've always been of the
"100% backwards compatible" school of thought.  That will eventually kill
something.  Evolve or die, basically.

> filePro's original power was it's ability to create applications 
> rapidly. To remain "current" we've had to do a lot of low level stuff 
> that should be done with a single filePro verb.

That's still its power.  I don't see the language as anything great, but
screen and report creation, and the engines that utilise screens and
reports are big keys.  The language is sufficient, so it could stay.

> One of the things that keeps poping up on this list is import/export 
> issues. A full suite of import and export tools. Working with Xbase 
> files, Excel files, MDB tables, XML files. Not via OBDC, but as an 
> external file. Keep It Simple, make it easy to use.
> 
> I know it sounds like heresy to think that anyone would want to export 
> data from filePro to be used in an other application. Heck, not only 
> have the animals gotten out of the fence, but they've paved over the 
> corral, everyone's moved to the suburbs, and five guys in sunglasses are 
> running around doing a complete makeover on a worn out brownstone where 
> the gate once was.

Ya think?  Sometimes it's a no-choice situation.  IIS 6.0 is your only
choice on Win2K3.  IIS 6.0 does not support drive letters, and -requires-
UNC syntax. filePro will not work in a web-enabled environment with
-anything- under that kind of environment.  Anyone migrating upwards might
want to bear that in mind.  And I didn't see it in the 5.0.14 feature
additinons.

> I'd like a professional IDE. Not character based. We gotta kill the 
> Tandy DT-100 mentality. Color coded with building block icons. Heck it 
> could/should be web based written in JAVA. End users don't specify 
> filePro. Developers build in filePro because we used to be able to 
> deliver state of the art applications quickly. That racetrack now is a 
> apartment complex with a 24 hour mall and a riverboat casino.
> I should be able to drag an export icon to the processing table and it 
> should ask me what I want, and tell me if I made a mistake, and show me 
> an example of what my choices would look like. If I wasn't so lazy in 
> the first place I'd of written apps in 1987 in assembly like I used to 
> do on my Commodore 64.

I have to partially disagree.  I have never, and will never believe that
full-scale data entry belongs in a GUI.  However, if one was to do a GUI,
it should be a -TRUE- GUI, not that half-baked thing that is GI.  I've seen
people do better by marking up fP screens with Multiview Catalyst.

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.

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.

> Kill processing table line length limits.
> Kill report width limits.
> LOCKEDBY(file) array to return @id of lock-er

Oh, you wanted things that could actually be done in this lifetime.  :)

Kill 80x24 screen limits.

Dynamicize index rvalues in the LOOKUP command--it's the one part that
isn't variable-friendly.

Actually be polite and DIE OFF when your parent processes have received a
signal (HUP, TERM, INT, etc.), instead of hanging around.

UNIXTIME()
PID()

Internal generic XML parser that will handle DTD and schema.  (I'd consider
an exporter really lame, since it's easy enough to write the files anyway,
but I know some that would grouse until they also got an exporter to make
it dead simple.  It's the parser that's really needed.)

> Well that's enough ranting.

I didn't hear a rant.  You have valid points.  I'll just agree to disagree
about GUI.  In many ways, it's easier to develop for GUI than it is for the
console (having coded in both Tk and curses, I can say that GUI was
actually the easier of the two, once you get used to it--given a decent
widget library, it's a lot less to keep track of).  For -some- applications,
I could see it.  For hardcore 8hrs/day data entry--no way in hell.  I did
that for a living for a few years.  The -most- efficient thing I worked
under was actually CICS.  You could fly on that, same as you can in fP.
There's something about proportional fonts and various other elements of
certain GUI designs that just make data entry a lot less efficient.  And if
I have to touch a mouse--forget it.  Training users properly is cheaper
than GUI design anyway.  :)

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html