What should fp 6.0 look like?

[Jay R. Ashworth]

On Thu, Oct 21, 2004 at 04:55:39PM -0400, Walter Vaughan wrote:
> Kenneth Brody wrote:
> > I have a POP3 client written in filePro 6.0, if that helps.  ;-)
> 
> 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?

Hmmmm...

(Yes, I am still alive.  Though, alas, my mom isn't.  :-{)

> One of the huge issues/problems with memos were the inability to print 
> them on reports. Well that's been fixed in 5.0.14.

If it works for you.  :-)

> So. What's needed in a 5.1 or 6.0? I mean, what features that could be 
> added to 5.0.14 that are currently not being met that would cause 
> developers to purchase and encourage their customers to upgrade in 
> significant percentages?

Reliably solid error messages that always reflect what actually broke?

> It's not like filePro is unstable. 99% of sites today could last fine 
> until 2028 and the hardware gives out or the last of the developers give 
> out and start pushing up daisies.

2038, when the time_t's wrap around.  :-)

> 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.

There's a balance you need to strike.

You need highlevel verbs to do common things, with good defaults, but
you need the available low-level knobs to make it possiblt to do
off-the-beaten-path stuff without having to reimplement something that
is there, but not flexible enough.  

Like browse lookups, and all the knobs they've grown over the years.

But, AFAIC, the number one item that needs to happen or you shouldn't
even be calling it "6" (the current version is, if you apply what there
is of an industry standard to version numbering, about 3.4 or so :-) is
header/detail handling that you don't have to write yourself.

This could be done as merely an "active" or "Editable" browse lookup,
if there isn't any obvious way to do it directly on the screen; as long
as the indexing and locking could be handled correctly, that would be
enough.

Cause, y'know, over reimplementing that myself.

> 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.

Two Words: Commercial Opportunity.

> 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.

:-)

> I'd like a professional IDE. Not character based. We gotta kill the 
> Tandy DT-100 mentality.

So saith you.  Greenscreens are your friend, dude.  Really.  Good GUI
useful *too*, but I can't run a GUI app from my Blackberry.

>                          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.

Fine.  So we need both.

Two words: commercial opportunity.

If the backend with the text screens and the programming language is
*architected correctly*, you can drop all that stuff on top.

> Kill processing table line length limits.

Yeah.

> Kill report width limits.

Whoa, yeah.  As well, as Mark notes, as screen size limits.  Why
*can't* I scrool?

> LOCKEDBY(file) array to return @id of lock-er

And, Ken's arguments notwithstanding, there *has* to be a way to
engineer this.  Perhaps it will take another lock table for the clients
(which surely know who's running them) to store it in.  So be it.

> Well that's enough ranting.

Not *near* enough.  :-)

Cheers,
-- jra
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"You know: I'm a fan of photosynthesis as much as the next guy,
	but if God merely wanted us to smell the flowers, he wouldn't 
	have invented a 3GHz microprocessor and a 3D graphics board."
					-- Luke Girardi