More on fP 6.0 features

[Fairlight]

Is it just me, or did John Esak say:
> 
> You may have noticed that I have been (conspicuously) quiet on all this 6.0
> stuff. I am far more concerned with getting a good 5.1 sometime during the
> 18 month dev cycle I think there should be until 6.0. So, I have just have
> one comment/question for you Mark.

I had a hunch you would pop in and bonk me on the head, so to speak.  :)

> Just _exactly_ where (to which precise/exact/name-please product) are all
> these filePro developers departing to... what is the "greener" pasture?  I
> mean, seriously now, this time I want a precise answer. Are you seriously
> telling me there is some "drop-in" package out there, some database engine,
> some _anything_ that will allow a filePro developer to migrate his packages
> over easily and thoroughly?  Hell, forget easily, just do the thoroughly
> part... I don't mind a little work... easy isn't a consideration... but I'll
> kiss your butt on national TV (in prime time) if you can show me _any_
> development tool/program/database out there that would allow me or anyone to
> convert a typical filePro application to "its" environment in less than 6
> months. Now, for typical filePro application... in my case they represent, a
> completely dynamic (full-scale) accounting system including G/L, A/P, A/R
> and P/R... (running several companies, many in the $20 to $50 million dollar
> range in sales, 20,000 invoices/P.O.s a year, etc., etc.) Now add to that
> the completely integrated Order Entry module and all the
> Shipping/fulfillment system.  Then, be sure to add in the also-fully
> integrated Production system complete with bar-code tracking from moment of
> production through bill-of-lading.  After those are done, add in the also
> fully integrated rolodex/customer/vendor system, Quality Control System and
> about 200 other small (yet fully integrated) applications that make a
> company run.  Heck, throw away the 6 month time limit... I'll even give you
> a year, how's that?  :-)

I'm not saying greener in the sense of RAD.  I'm saying in the sense of,
say, an international corporation's worldwide regional divisions all
needing to talk to one another, four out of five run Oracle, and there's a
gap there for communications breakdown.  Lots of things they can do, but
they're workarounds at best, and people higher up than the regional IT
department demand a change to get things uniform.  Or organisations that
have to deal with governmental agencies running *SQL, and the government
(local or state in this case, can't remember which) simply -won't- be
switching, so you're at their mercy, because 95% of your workload revolves
around doing business with them, so you have no choice but to compromise.

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.

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.

> The point is, I don't think I'm going to be kissing your butt any time soon.
> Such a single package (nay, no group of packages)... nothing out there would
> allow me to migrate into a brand new filePro-free environment in any
> "reasonable" space of time... and I'm one helluva good filePro developer
> with a colleague now in Rick who is just as good... and the both of us
> couldn't do this kind of job in 6 months or a year.... not with anything I
> know.  The very best possibility you could mention might be FileMaker Pro,
> and just the conversion to that product alone would be a gargantuan task. So
> where is this greener valley?

It's not necessarily greener in terms of cost.  More often than not, you're
not only blowing the investment you already had in years of fP development,
but you're spending more for development in these other environments.  I
don't deny that for a second.

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.

> Now, I'll admit completely that FileMaker Pro has a tool set and feature
> list that leaves filePro looking like the 25 year old legacy program that it
> is... leaves it in the dust. I mean there are things in FileMaker Pro that
> allow you to instantly web-enable your applications and much, much more.
> There is database integration on a level filePro could not possibly hope to
> even simulate. Is it the product people should move to from filePro?  I
> suppose... it's only $149 per seat (plus some amount for the servers...)

I haven't actually heard of anyone dumping fP for FMP in practice--just
picking up a copy to evaluate against.  Each one comes up on top in some
areas, on the bottom in others.

> Hell, there is almost no price we wouldn't pay to move fully integrated
> filePro apps to something new and modern-systems-based so it has the ability
> to stay "new" for the next decade or so... but the transition to such a
> product, like FMP would put us out of business.  I wouldn't worry about
> _most_ major filePro developers and their apps... because all the same
> things apply. It is just too much of a transition, not just for the
> programs, but for the inertia of the companies and people involved and the
> way they have come to do business and rely on filePro... which absolutely
> _nobody_ can deny is "rock-solid". There are very few times when filePro
> will be the cause of a problem... and when such a thing occurs and is
> transmitted to FP Tech, it gets fixed. I'm not sure how that would go with
> other "greener valley" programs.

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.

Now there are two sides to this.  One point is that there was a huge
outlay to do so.  There's no getting around that, as there's really no
easy way to do the business rule transition, much less interface issues.
Data conversion is pretty straightforward in many cases, but still a
bit dicey if you have funky data--and you still need to generate unique
fields (which, I gather from some discussions, is kind of an issue with
fPODBC, where fP doesn't require unique fields but the target databases
do? [half-statement, half-question]).  The other point, however, is
that there is a much broader pool of professionals that know *SQL and
perl/PHP/ColdFusion/Java than know filePro.  If your developer gets run
over by a truck, God forbid, you could be more than a bit put out to get
mods, completion of any ongoing development, bug fixes, etc., from someone
that not only doesn't know your company and your system, but has to learn
a whole new platform as well.  You can pluck one of the developers for
these other solution combinations off the shelf, practically.  Like MCSE's,
they're a dime a dozen--the trick is more in picking a highly skilled one
over a mediocre-to-poor one.

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 organisations and
external organisations with which they do business, etc.

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

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?

Maybe I don't stress MySQL enough to notice, but I've never had a problem
with the engine, actually.  Most times, the issues I run into are with
my own logic in perl, and it's my own fault.  The question you pose is
really hard to address, as other solutions are really a multi-vendor
approach.  You have your RDBMS, and you have your application/UI.  The two
don't generally come from the same place unless you go with something like
Oracle's Enterprise type tools, or something as chintzy as Access.  

Usually it's disparate.  You can put ColdFusion up against multiple SQL
engines, all from different vendors.  Not being the "one thing that does
everything" model, it's hard to compare that to fP's bug-fixing/support.
As far as perl goes, bug fixes are handled pretty fast.  ColdFusion seemed
to have okay support when I was dealing with the guys that were coding in
it, although I'm not fond of Macromedia myself.  Oracle was rumoured to
be considering scheduled updates rather than intermittant, more frequent
updates--similar to what MS has done with their software patch schedules.
MySQL is releasing any security holes as they're discovered and I've heard
of no plans to change that.  Jay or someone else would have to speak for
PgSQL.  PHP...hell, I won't even touch it.  They change the API more often
than I change the oil in my car from the looks of it--things that you
can use in one minor release vanish from the next minor release without
warning.  It's too fast a moving target and too immature a language to be
viable for enterprise use, IMHO.  I've heard people say perl looked like a
moving target, but it looks positively plodding compared to PHP's release
schedules.  I'd actually rather use fP than PHP + whatever -myself- given
the choice, which should tell you how much I dislike PHP. :) Java...Sun's
Sun.  You know them.  Others would know more about the specifics there,
as I won't go near it.  There'll always be C, but development in C takes
a long, long time compared to just about any of the above, higher-level
languages, unless you're one of those insane kernel hackers that just spews
out a few thousand lines a night while under the influence of much alcohol.

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.

> So, while I thoroughly agree the tool set needs to be improved and fixed and
> added to. I think (and we may agree on this) all that is for 5.1.  The idea
> of 6.0 filePro should be to change the entire schema/engine/thing to be new
> and damn the compatibility. I would much rather convert my giant,
> integrated, long-standing filePro applications to something called 6.0
> filePro than to anything with any other name... no matter how close it
> sounds.

And I'm in agreement.  They should release a 5.1 that should clear out
remaining bug issues and address small to medium sized issues.  Screen
size would fall in there, IMHO.  UNC support so IIS 6.0 doesn't break it
with remote data storage locations.  A bunch of things.  I'm just not
sure though, how compelling even those kinds of fixes will be in moving
more product.  I don't know what they did in terms of moving 5.0, but
I can say that even with what they did add, they have a lot of people
(even on this list, let alone everywhere else) hanging desperately onto
their 4.8 and even 4.5 versions--people who have yet to feel there was a
compelling feature set for which it was worth paying to upgrade.  More
than a few people, in my estimation, upgraded to 5.0 on the basis of the
ever-pending ODBC.  And those that did so for *nix systems got the giant
shaft on that move.  But for some, that was the reason they even bit in the
first place--on the promise of a feature that ended up only being delivered
to Windows users.

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

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.

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.

If it's not compelling enough a feature list, only long-time users and
loyalists will buy into it, and the company will possibly not even break
even on the R&D cycle, much less profit from releasing a new version.

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

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
I know are fully aware of 5.0 and the shortcomings of 4.5 and 4.8, but who
still cling to those versions, I'd say that 5.0 wasn't adopted terribly
well.  I'd say the promised ODBC was one of the most compelling reasons
to upgrade, and even that didn't do it for many.  The internal features
that were added apparently didn't have enough value.  So whatever they're
planning, I'm thinking it better big a case of Think Big if they want it to
take off, rather than flop on its side and gasp for air.  Not just big, but
wide in scope and broad in appeal.

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
I don't think 5.1 can be a charge-for upgrade but only deliver a minimal
feature list that, say...might largely cater to the new Biometrics pet (I
could see that happening, given the direction their marketing seems to
have gone this year), rather than address core product issues.  I think it
would be rebuffed, by and large.  Much as people like the product, this is
business, not charity.  A few people saying that "everyone should upgrade"
will only go so far.  It has to be able stand on its own merits without
anyone shilling for it, to be a viable charged upgrade.

And last I heard from the rumour mill, 5.1 -was- planned.  Then Ken started
with this 6.0 stuff last week or so, and I assumed they were just skipping
5.1 altogether.  I don't know how accurate that assumption is, but it's the
impression I got.

Good gravy, this got way, way too long.  Still, I hope I rationally
addressed your questions sufficiently, as well as clarified my case for why
I think they should pursue a specific course.

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