FW: The FP Room: Meeting with Ken and Laura Brody

[Fairlight]

When asked his whereabouts on Sun, Jan 09, 2005 at 06:00:02PM -0600,
Mike Schwartz-PC Support & Services took the fifth, drank it, and then slurred:
> 
> 	I'll take another look at wireless headsets.  

Let me know if you find anything that's under $100.  :)  I'm willing to go
up to that, but past that point, I'll tolerate the wire.

> 	I almost hesitated to use the word legacy, because I spend most of
> my working day updating and improving these legacy apps and keeping them
> viable for the foreseeable future.  

How's PayPal integration strike you? :) That's on my plate right now.  Full
IPN with full data population.  One of the key things that's been missing
from online transactions has been getting paid online.  This will cover
every transaction type possible through PayPal, which accepts VISA, MC,
Discover, and AMEX, as well as eCheck.

> 	The legacy moniker is usually hung on these kind of apps by younger
> people who hang it on any app not written in visual basic.

Bleah.  You couldn't pay me to touch VB outside the context of an Excel
macro, in which case you have no choice.

For my part, it's a matter of "structured" in the conventional sense (I
wish Laura had actually done her proposed fPStruct), versus the native
language's syntax and structure.  I -can- program in it, but I have to
change gears drastically and slow my brain down to about 25% to be able to
focus on doing it without screwing things up.  (Why are things never
screwed down?)

I just accept the differences nowadays.  I'll gripe occasionally if I
get saddled with something that's just plain easier with a conventional
structured language, but not bitch too strenuously anymore.  I must be
getting old; I'm losing some of my fire.  I guess that's a Good Thing, all
things considered.

As for "legacy", it seems that this is applied even more generally to
anything that's not a -full- GUI (GI need not apply).  Thing is...there
were 3 or 4 of us in the room the other night discussing just how powerful
fP would be if they abstracted the I/O API and let you use the RAD toolkit
against other storage engines--particularly simultaneously.  I'm not the
only one that thinks this would not only help fP tremendously in its
current context, but that it would open up a whole second front on which
you could market heavily--console (text terminal) based RAD development for
*SQL databases.  Can you say, "Kick-ass?"  :)  I still say it would rock to
be able to have one processing table open and be talking to MSSQL, MySQL,
PgSQL, Oracle, DB2, and native fP, and exchang data seamlessly between them
the way you would between the current lookup handles.  That alone is worth
it.  But to be able to corner the market on text-based RAD for *SQL?  I
have yet to find a non-GUI solution for that.

There are those out there who know that terminals are still a great way to
go for the real hardcore data entry.

Maybe in filePro II...  :)

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