FW: fPSA

[John Esak]

Dear Eduardo,

I hope you will not mind, but I am going to forward this note of yours to
the filePro Mailing List. It is SO well written and SO clearly stated that
it is a waste just to send it to me alone. You apologize at the end for your
English, but I wish I could express myself half as well as you in my *own*
language. :-)

I will add my comments at the end, but you have said it all.


-----Original Message-----
From: Eduardo Fernandez [mailto:edferna at dynamo.com.ar]
Sent: Thursday, August 04, 2005 10:01 PM
To: john at valar.com
Subject: fPSA


Dear John:

I have read about your fPSA project and I think it is simply a marvelous
idea.

I am excited waiting for the arrival of Survival CD´s series and of course
for the first issue of the Addendum CD

As a Profile user since the early days of the TRSDOS version, through the
Tandy Xenix series up to now, I was  searching for add-ons, literature,
magazines and books to improve my programs and to learn as much as possible,
seeing how other people were doing things and solving problems using
FilePro.

But as you know the offer was scarce.

And our patience as filePro users was stressed and tested to the limits.

I remember the endless wait for the fpWin version, or the ODBC interface
that finally arrived but for our deception it was only the client side.

The eternal discussion that populated the filepro-list over the last 5 years
about the pro´s and con´s on being tied to the old fp architecture finally
arrived to my home.

Two of my sons, very well trained and smart programmers, are helping me to
develop and maintain a large collection of filePro programs that I wrote
over the last 20 years for the manufacturing company I work for.

But every time we deal with a new project, They emphasize the fp limitations
trying to convince me of migrating to a new development platform and to a
new database engine (mySQL).

In fact one of them is finishing an interface that will read and write fp
tables and keep automatic indexes updated from the outside world (be it
mySQL or any other application).

This product will allow us to choose the best of both worlds and to migrate
data smoothly and progressively to and from filePro.

I still keep my heart and my loyalty to the database I learned first and I
lived with for at least 22 years.

I also prefer a system I can quickly setup and adapt to changing conditions
than a more sophisticated one requiring a lot of time to develop, debug and
service.

My sons have the power of young people and the open minded attitude to
search for the best available option.

I became more and more an orthodox and cautious man, privileging the system
availability and functionality of an old well known and imperfect product
over the extra features of any not so well known alternative.

But it is not easy to sustain my position, and it is also not easy to take
the decision and to implement an eventual migration without disturbing a
working environment.

I know that you also have developed a very large set of sophisticated fp
programs for a manufacturing company and I remember a recent thread in which
you analyzed the advantages and disadvantages of filePro as platform as well
as the risks involved and the time required for any migration.

But coming back to your fPSA idea, I think it will fill the long awaited
need for a good source of programming tips and tricks.

By the way If you want or need to translate any of your articles to Spanish,
I can help you to do that or at least to review the final text.

I apologize for my poor English and once again, my congratulations for your
continuous effort.

Best Regards



Eduardo Fernandez
Argentina


<my vollow-on -JE>

I am continually considering other databases besides filePro... have been
for more than 15 years now. It's not that I have ever found better or not.
There are, of course, RDBMS offerings out there which are staggering in what
they do and can do for a user/developer. There is fileMaker Pro,  sheesh,
what a rip-off of our name, huh?  It is simply phenomenal these days with an
upcoming convention in Arizona to show off even newer and more powerful
things. For example, build a complete app, press a button and BANG! it is an
app that works on the web. Pretty compelling.  There is FoxPro, still a
major player believe it or not. It has the amazing ability of letting you
develop an entire app and then compile it all into one .exe that you can
distribute royalty free, with no user-licensing limitations. Amazing. (By
the way fileMaker Pro remains very pricey to use over a middle-sized to
large-sized enterprise... that is one of its only drawbacks.) The other big
player of course is Oracle... just can't even consider this as a solution
for small-to-middle size systems... it is too pricey and way too much to
control. Hard to easily develop things in it without many, many people
working on the project. As for MySQL and other smaller less expensive
engines... yes, they are probably the best bet for most filePro
transformations and enhancements... but in this case, it is all about
implementation. Understanding the full implications of how to design good
apps with this base is not something that will just "come to you". It takes
years of learning experience to progress to the same point you (we) are
already at with our 20+ years of filePro know-how. And truly, MySQL alone is
not going to do _anything_ for you without a whole slew of other tools, like
PERL at least. And learning PERL enough to make MySQL do its thing is a
lifetime career in itself. Sure you can use anything besides PERL, like
Visual Basic, but the point is, these other ready-to-go database engines are
not that... ready-to-go. They merely allow SQL-savvy users to use them. This
may be a plus in today's world... but I discount it pretty heavily, as I'd
rather have my user-base knowing about my product and their actual business
rather than how to finagle the data they want out of a database.

You are so right about it being a younger person's game. It's not that I
don't have the time, I don't have the desire. :-)  Therefore, to accommodate
the "new" requirements of today's business needs, and there are some pretty
complex requirements, I have chosen a fixed and immutable path. We have
(long ago actually) made the decision to stay whole-heartedly with
filePro... and make use of the follow on protocols and systems which allow
us to add the new functionality _without_ running to a new base engine. It
is better for us to work with XML for example to gather and send EDI than to
buy into expensive hard to integrate canned applications. (Hint to
filePro-authors... build in some XML functionality!!!) It is easier for us
to access ODBC apps from filePro than move to an full ODBC database
ourselves. Yes, it was/is bad to find that just the client-side is
available. We have known this for 5 years and the wait just for that much
functionality probably lost the most users of filePro overall throughout its
long history. Even so, being able to lookup to and post things back and
forth from ODBC apps like UPS' World Ship has been just great. Even that
much new ability has helped me with our commitment to filePro.

It is SO hard when new blood comes into the company and says... "What the
hell is fielPro??  Why aren't you using such-and-such???"  All we can do is
say, "Gee, we'd like to... perhaps, but are YOU willing to put in the 20+
years developing what we already have to make it worthwhile for us to
switch?"  At this point, the situation always gets back to reality. In our
case, and I'm sure hundreds of other places around the world, the better
choice is to continue integration with filePro rather than moving away from
it. I think that will never change.

To the future, I say what I have always said regarding filePro. The authors
should lean heavily toward enhancing the system and licensing to be better
able to work "with the web". The data itself needs to be encrypted somehow.
The interface to GUI has to be accomplished at some point in a way that is
fluid and complete... and FAST... and that's about it. Just do all that, and
you won't lose anyone to any other product or engine. We can deal with the
shortcomings of its basic design not being a RDB... although that
functionality is awesome. We can deal with not having it. The other things
are going to be harder and harder to defend against. HELP! :-)

John Esak

P.S. - Only one small thing. The company (whoever owned filePro at the time)
did not actually deceive us regarding ODBC. They never promised anything
more than client-side ODBC from the very outset. The first investigations
proved that it would be essentially impossible to implement server side ODBC
for filePro, and I don't think they ever lied about this. We take what we
can get. :-)