More on fP 6.0 features

[John Esak]

Sheesh, do you type a buzz of words, or what...?

I'm considering top-posting... hell, nah, I'll just cut most of what you
said... we agree on most of it. Let me just add a couple things to some of
the points.

1) First I'm glad I don't have to kiss your butt.  :-)
2) I truly believe that Ken's ;-) after the 6.0 reference was pretty clear
that he was kidding. And, by the way, this is meaningless... but somehow
important... I have seen and worked with a tiny POP3 client that Ken wrote
before 4.8 came out! It was cool enough at a first shot of probably 30 lines
of code to be a sellable app... but that's another story. :-)

3) Now I'll start the cut and paste... but I really don't have much to add.


> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com
> [mailto:filepro-list-bounces at lists.celestial.com]On Behalf Of Fairlight


> Is there another RAD out there that will let you develop as easily as
> filePro, or as quickly?  Not in the character-based world, no.  I haven't
> explored the GUI side thoroughly, but I know there are things out there
> like Delphi and Kylix.  I can't vouch for simplicity or speed, but I would
> assume they're decent, both being from Borland, whom I've
> respected from ye
> olden days.

Haven't seen them...

>
> So, you want to know what I've seen people dump filePro for?
>
> perl + *SQL
> PHP + *SQL
> ColdFusion and *SQL
> Java and *SQL in one case
> Access (believe it or not!--now -there-'s a move even -I- think
> is suicide)
>
> The SQL back-ends have run the gamut among MySQL, PgSQL, MSSQL, Oracle,
> and SyBase (notably with ColdFusion for some reason).
>
> How do they migrate?  Total rewrite of their software enterprise.  No, I'm
> not kidding.  They need to accomplish something, they're given no
> leeway or
> latitude, and they have no choice but to develop a plan to migrate, and to
> follow that plan to the bitter end--no matter the cost.  It's not
> always IT
> calling the shots, unfortunately.  I've seen IT have to defer to the CFO
> more times than I care to remember.

Me too, it's sad, but the above set of tools is too fragmented and that lack
of a cohesive design platform makes it all the harder. Yes the SQL stuff is
inviting, and it's "there", but there is a chasm of difference between
SQL-based apps and filePro's apps. I do grant that for the future, perhaps
the new paradigm is the only way many organizations are being forced to
go... but it really doesn't make it better, easier, cost-effective, good,
useful, etc., etc.  It just makes your apps more conversant with what is out
there and what will continue to be out there... so I have no disagreement
here. (But I do generally hate SQL... :-)

>
> I would say "greener" strictly from the standpoint of interoperability.
> And this is why I again put forth the concept of abstracting the storage
> engine.  If you could do multiple lookups to Oracle, MySQL, PgSQL, and
> MSSQL as needed, in a single table, -as well as- using the native filePro
> data you already have, suddenly you have a RAD kit not only just for fP's
> native storage, but you've just cornered the character-based market on RAD
> for *SQL.  That's "all" it takes, is dropping the storage and retrieval
> API to the level of module and adding the appropriate other modules--all
> of which are either documented decently already, or there are perl modules
> and/or C libraries already written open-source that could be used for
> reference.

Excellent... of course this would be great... My question is why hasn't this
sort of thing been the past four years work for FP Tech... why did the work
on ODBC stop when it was essentially done... with no new development
considered (like *nix) and some of the things you mention above. How did
Biometrics come to be the thing that took so much of the developer's time? I
think this was a bad mistake. However, with the company never using any of
the input it is always asking for... it is easy to see how something
completely out of left field came in and took the central position... when,
clearly, the core product should have been developing a-pace with other such
things as Biometrics being on the warm and back burners perhaps.  I feel
like a staunch republican taking pot shots at Bush... I don't mean to do
this to FP Tech... but at every conference they ask for suggestions, put out
real, obviously well-intentioned requests for ideas and wish-lists and
such... then, somehow completely lose them for things out-of-the-blue, like
Biometrics.  On the other hand and in their defense, the biggest
"want/wish/suggestion" from every developer 4 years ago was GUI... give us
mouse-ability.  Well, they did do that, but unfortunately, it was done in a
way that tried desperately to keep backward compatibility (also SUPER high
on every developer's list) and this _crippled_ the product into being a
slow, nearly useless hybrid of stuff which can't even do the simplest thing
a GUI does, like size the screen, etc. God,I hate to be so harsh, but when I
first saw fpGI it looked like it was going to be exactly the direction
filePro needed... then it quickly degenerated into what it is... and
unfortunately again, it is not going to be the product which moves filePro
into the future. From almost 3 years ago it was obviously not going to fill
anyone's needs. All development and resources should have been moved to
other things at that point. Again, this is all just IMO as an outsider. Most
of FP Tech's decisions, if not all over the long life of this product have
never been publicized or up for debate in any way. I wish they had been.


>
> What I've been trying to convey is that people -have- bitten the bullet
> and gone from entirely fP-based solutions (with custom CGI, no less)
> to ColdFusion and MSSQL, for example.  I can think of (though as a
> professional issue, I will not name) one company where that was
> -precisely-
> the migration--filePro with custom CGI to ColdFusion and MSSQL,
> all done by
> the same programmer, who could work under either environment.  They sank a
> -lot- of capital into redevelopment, to be sure, not to mention cartloads
> of time.  And that was an application that I gather wasn't around for more
> than a few years prior to being rewritten.

Unfortunately, (and I'm using that word a lot, huh) the "biting the bullet"
is the catch phrase here. There simply is no analog for this in our
(Nexus's) situation.  Biting the bullet to completely move to a non-filePro
solution for our company would be just great, but as I said, it would put us
out of business. We have to continue on doing business as we are... and
don't feel sorry for us... filePro has allowed us to implement systems that
are the pure envy of our industry. All of our competitors are constantly
trying to duplicate the things we do, from full EDI to production reporting,
to industry-leading bar coding, to etc., etc. We have it all right now with
filePro... except for easy integration to/with the RDBMS based stuff out
there... and the ODBC feature, even though Windows-based, is giving us a
real handle on that, too. But these aspects of filePro that are only
partially there... as well as only an atomic-level HTML command set, do make
it all very hard.  But, once again, and not to "shill" for filePro in any
way, our company is so far ahead of _any_ other company in our industry that
you could name... in all important areas... we just are.  Keeping that way
is what this discussion is all about, and I have to agree with you... it is
crucially important what filePro decides to look like in the future.


> I'm looking right now at someone that's possibly going to have to move
> away from fP.  They'd rather not, as the amount of interoperability hooks
> between various subsystems is enormous, and rewriting just the fP in
> something else is going to be a nightmare--bad enough they'd rather not
> think about it.  But the decision's not theirs, because fP isn't
> delivering
> what they need.  People don't have time--they're under pressure to migrate
> to newer platforms, become compliant within their own organizations and
> external organizations with which they do business, etc.

Yes, it is a big problem, the pressure any company can get from "higher up"
and from outside (especially *customers*).  I sympathize with them.


>
> But in direct answer to your question, no, there's -no- magic bullet
> or set of migration tools.  Not that I'm aware of.  It's blood, sweat,
> and tears all the way, no two ways about it.  The more involved the
> infrastructure, the worse it is.  But people are doing it--sometimes under
> duress, sometimes out of frustration.  I can tell you want people are
> moving to, and I can tell you that those things -do- play far more nicely
> and readily with the rest of the world's software without arcane
> middleware
> and cobbled workarounds.  I can't tell you that it's fast or inexpensive,
> I'd be outright lying.

That is all I was initially trying to get you say when I first "bonked in"
on this thread. None, more than I wish there was a migration path to
integrate filePro with all that is out there. ODBC is the very best of
starts... it should have been the focus for the past several years.

> Bill Vermillion has a good anecdote about one
> location that decided that moving their app from fP to something else was
> a good idea, and paid for it in spades.  Then again, sometimes there are
> compelling, unignorable reasons for doing so, and it simply is the only
> sane alternative left, without jerry-rigging things to hades and back.  No
> matter the reasons, it's not inexpensive, and it bears a great deal of
> consideration.  I'd be lying if I said it was easy.  But I'd also be lying
> if I said people weren't taking a header and doing it anyway, sometimes
> with very good reason.

It's that "taking a header" phrase (much like the "bite the bullet" one)
that has no *real* meaning. We can't just tell our 150 families that the
company is going to stop doing business (or at worst, do mixed-up, confused,
half functioning, half not yet functioning) things while we take the header
into an essentially empty swimming pool. Migration is about smooth, seamless
progression from one thing to another. None of the systems we use lend
themselves to that.


> As for support...fP bugfix versions have been relatively sparse, if we're
> going by the last minor number.  I have reason to fully believe
> fP-Tech was
> probably aware of UNC and IIS 6.0 well before 5.0.14, yet it's -not- fixed
> yet.  I'd call it a problem when your database can't find its own data
> files.  :(  And Ken says this is an easy fix.  So why is it absent?

I think bugfixes should come out *immediately*. I think minor level versions
should go through beta quickly and come out much more frequently.  I think
5.1 should be a "for-money" upgrade that is _compelling_ as you suggest...
and after that... 6.0 should be a new "break-away/no compatibility" product
that provides hooks and possibly some conversion help tools for legacy
filePro.

As to features to 5.1 which would make it highly desirable... we all have
our own wishlists. I have been patiently putting mine into the official
wishlist.  Unfortunately, (there's that word again) I think it only gets
looked at periodically but not seriously considered. [By the way a couple of
my personal favorite wishlist items for 5.1...

1) More than 16 automatic indexes... how about down to Z (yes I know, you
have to figure out the X problem... why not just skip it? :-)

2) Expressions for import/export subscripts.

3) Some enhancement to popups on popups.

I could go on... but why? There all in the official wishlist along with so
many others from so many other people. Instead of most of these wishlist
items (translate this to desperately needed new features if you like) we got
a Biometrics module that works with a particular piece of hardware... and
single user. [although this may be multi-user now, I don't know.]

>
> But you get the idea...you're dealing with multiple vendors in an entirely
> different paradigm than what you're used to with fP.  So the question is
> hard to address with any amount of "apples to apples" clarity.  I'd like
> to, but it's not really possible to directly compare.

Yes, as you can see, I've been agreeing. Which leads me to say (and
hopefully this will counter all the seemingly disparaging things I've just
said about filePro) it is simply fantastic that it has been able to fulfill
98% of our companies needs in 98% of the areas we need computing power.
There is nothing like it... and we, at least, will never switch from it. I
will continue to adapt it and integrate it as best I can until it evolves
into something newer and better... which I think it will. In the meantime,
we too, are always looking at other things like FileMaker Pro... why not?
It's fun to guess how long it would take to migrate over even one of our
systems.  As far as migrating to a multi-tool/multi-vendor situation which
as you say is the only possibility now.... I'd rather cut my head off and
jump off our building.

>
> But 6.0, I really think that if they want to get serious about it, they
> should consider the idea of using more than just their own storage code.
> They could vastly facilitate the interoperability between platforms within
> divisions or organizations (even just departments, depending how large
> or small the company is).  It would suddenly allow you and everyone else
> to not have to do more than use a slightly different lookup syntax, if
> done properly.  That would be the penultimate.  Then they'd have the
> RAD UI and reports, and easy language everyone seems to like, with the
> ability to speak directly with everything reasonable under the sun that
> is new.  That's exactly what I think the end goal should be.  It would
> grab purchases from both people that need that interoperability, as well
> as fresh, new people that want RAD console/terminal non-GUI apps.  And
> for those that want GUI, well...I guess there's fPGI (*unenthusiastically
> said*). :) They're not likely to dominate the GUI side of the RAD
> audience,
> but not everyone wants GUI.  There's a reason there are a tonne of GUI
> multi-protocol IM clients for *nix, but someone went to the trouble of
> writing centericq in curses, for example.  There was a reason for
> that--consoles and terminals are far more efficient for many, many people.

Sounds wonderful... what else can I say... other than I believe this would
be much harder than you make out... too bad.

>
> It could be the best of both worlds for current fP users, and it would
> widen their appeal and audience, IMHO.  You could literally keep your old
> code in place, start migrating your data by inserting additional lookups
> and updates to other data sources, get what data you need onto
> newer storage
> engines that anything in the world can talk to--yet internally
> you'd retain
> the advantage of fP's language, RAD, UI, reports, lack of a need
> to retrain
> people, etc.  It's win-win.  And yet, I can psychically hear the thoughts
> of TPTB whispering in my ear, "Yes, but if we adopt other formats, more
> people will leave."  I don't think so.  They don't have a reason to leave
> if you let them keep their 15-20+ years of experience and investment AND
> let them have interoperability as well.  Why leave, when you can take the
> course of least resistance and simply export which portions you must to
> placate whomever, but keep the toolset you like, which is more
> cost-effective for you to develop with at this point in time?  You're
> simply dropping barriers that are causing people to leave, while inviting
> people to adopt in an area that (from what I can tell) is basically
> untapped--terminal/console-based RAD development for *SQL, in a language
> that you've been able to tout that "anyone can do it" for decades.  How is
> that a losing proposition?  It's not, IMHO.

Absolutely... sounds like I wrote this myself one time.

> Whatever they do, whether it be 5.1 or 6.0, they had better make it pretty
> darn compelling, or they're simply wasting time, resources, and money on
> creating a new version that a few die-hards will upgrade to, but
> which will
> not broaden the user base, and which--by omission of any key features that
> should and could be added byt may not be--may actually shrink the
> user base
> in the process.  Sometimes doing something is worse than doing nothing at
> all--if the something you do is executed poorly in the eyes of the
> beholder.  And in the software market, it's the buyer that's the beholder.

Again, we could not be more in agreement... but two things....

1) How do you do this with dwindling resources and income?

2) Nancy's (and other's like Bill Randall) idea that a clear and really
workable business/marketing plan are more important than the feature set.
FilePro's feature set has always been pretty cool for its little
character-based niche... awesome, in fact.  What it has always needed is a
good presence in the marketplace... amongst developers mostly. FilePro has
become so powerful... (and yes, my younger brother who knows nothing/NOTHING
about programming uses it all the time) that I think it has finally grown
completely out of anything an end user would/could choose. Learning it bit
by bit over the years gives most of us a terrific advantage. I think the
product should once and all call itself a development/developer's tool and
stop all attempt at staying accessible to the average "user".  Or (in Kerry
fashion, I flip-flop easily) it should incorporate hundreds of tiny wizards
and applets (and severlets) so that _anyone_ can accomplish the things one
could two decades ago ... even if they are not programmers.  Fish or cut
bait... but then again, I've never known why you can't do both? Meaning,
we're right back where we started from.


> Long story short:  Make it -really- good, or don't even bother.

Well, the only thing I can say to this is... for the past 25 years they have
done so... it has tripped up a bit in the past 3 or 4 years.... but I think
it can go back on track. I hope so.


> It's just too late in the game for half-hearted upgrades, IMHO, given the
> speed at which technology is advancing.  Based on the number of people who

It's never too late...


> I think it's fair to say one can only survive so long on runtime sales.
> The real money is probably on upgrades of devkits (and runtimes, but more
> the devkits).  If 5.1 isn't very compelling, people may not even wait for
> a 6.0, citing lack of any -real- forward momentum.  I've heard the words,
> "Too little, too late," from far too many people in the last few
> years.  So

You never know. When the Doors broke up, Ray, the keyboardist said to Jim
Morrison. "Hey you know I think we've still got some good blues albums in
us..."  Too bad they didn't make them. Anything can happen. One course and
source of income for FP Tech which would help fund new development of a new
filePro might be if a group of (their) programmers got together and built
the most complete, fully generic horizontal or vertical app. One so good
that it could be offered on any hardware system... They sell this to the
large customer list they have now... along with a hardware solution
supported by third party. Who wouldn't want a really great
Accounting-Point-of-Sale system for any one of the zillions of small
businesses out there... It's a read-to-go market and the RAD aspect of
filePro could have a few offerings ready pretty quickly. Why shouldn't the
company rely on its own product to generate income? I think this is a great
place to start.

John