Question for Tommorow's QnA with KB

[Fairlight]

On Mon, Jan 10, 2005 at 11:08:25AM -0500, after drawing runes in goat's blood,
Tim Fischer cast forth these immortal, mystical words:
> > Does anyone understand the question? Instead of trying to make OBDC work

Understand?  I posed the same thing a couple months back.  :)  But I went
so far as to say you could modify LOOKUP so that you could dictate which
I/O module was used under the the top-level API for any given handle.

In this fashion, fP could even broker between disparate SQL servers.  fP
having one table talking to native fP data files, a MySQL server, Oracle,
and an MSSQL server, for instance.

> This feature would effectively eliminate the need for FP.  Why use FP only
> as a front end?  I could probably create a front end that would work in the
> same way and probably look better (at least allow more flexibility) using C,
> and I don't really know C.  For your use, it would provide the functionality
> you listed.  But how many current FP users would abandon FP completely?

I wholly disagree, no offense intended.

fP would become more robust, as it would gain much-desired (if not needed,
which I feel it is, but the "fact" may be in dispute) functionality
internal and integral to its own use.  However, it -also- would provide
fP-Tech with a second (and broader) front on which to market fP:  as a RAD
toolkit for -text-based- (ie., NON-GUI) SQL development.

Why reinvent 25 years of wheel?  They have all the RAD tools there.  Sure,
you could slap an ncurses RAD kit together even in perl with Curses.pm, but
it's going to take a lot more time and resources than it would to just
abstract the I/O from fP, and it won't achieve the end-goal of negating the
need to entirely migrate and end up losing 20+ years of code that's been
built up.  People could just use the same code and use the added
connectivity, if they're already in fP.  No migration would be necessary,
but you could function a helluva lot more efficiently in a heterogeneous 
environment.  And the plus would be that you'd have a rull RAD toolkit for
non-gui for any SQL engine they support.  That's a hell of a plus, since no
such creature -appears- to exist.  Every solution I've found is GUI-only,
which just plain doesn't cut it.

If they did this, they'd also be eliminating their userbase erosion,
hopefully.  If people migrate, it's usually for features that the other
RDBMS engines have.  If the two can -talk-, they can probably get away with
a mixed environment, protect their internal investment in-house at whatever
organisation, and fP still gets to sell to these folks rather than lose
them entirely.

Aside from the cost of redeveloping the I/O abstraction layer and revising
the top-level language to accomodate the extra functionality, it's a
completely win-win situation for fP.

Why would anyone toss over fP for something else and lose their years'
worth of development investment if fP can suddenly talk to what is needed?
I'm not seeing the logic in that.  I think that's a little bit of fuzzy
logic.  The end goal is to save as much as you can of what you've done, and
still move forward with what you need to do.  This would accomplish that in
many cases.

However...to the OP:  I think this may be along the lines of the kind of
thing John is hoping to -avoid- for the discussion on Tuesday.  I mean, he
can correct me if I'm wrong, but even taken from a constructive point of
view (which I think we both share here), it's a focus on fP development and
what is lacking (or perceived as lacking) than it is a question on doing
things with the current implementation.  And John's comments seemed to
indicate -that- was the purpose of the event...to focus on how to do things
with the current implementation.  I plan on avoiding my own beheading by
refraining from such discussion on Tuesday.  :)

I'm more than happy to kick the discussion back and forth here or in the
voice chat and help further a dialogue with fP-Tech--just not during that
-particular- event given John's statements from the other day, which I'm
happy to respect.

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