More on fP 6.0 features

[Fairlight]

Confusious (John Esak) say:
> 
> Sheesh, do you type a buzz of words, or what...?

The curse of fast fingers.

> 1) First I'm glad I don't have to kiss your butt.  :-)

Me too, really.  I'm ticklish, for a start.  :)

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

How long has the network code been in filePro?  I was under the impression
just since 5.x.  I didn't take his comment about writing a POP3 client as a
joke.  Done a 'strings' on *clerk on a recent version?  It's linked against
the network stack, no doubt about it--and this would have to be intentional
on the SCO binaries.  And I believe I know why it's there.  So yeah, I
wouldn't doubt he has a functional POP3 client in filePro.  This will also
be good news for any future XML parser, since they'll need to retrieve
DTD's and schema that aren't included, but are instead linked.

I didn't take the smiley quite the same way, but I can't read Ken really
well most of the time.  I just don't know him well enough to be able to do
so accurately.  I defer to your judgement, since I believe you do.

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

Well, there is a lot of power inherent in the SQL apps.  You don't have to
micromanage your data relationships, for a start.  That the engines are
basically open to use via API's means that drivers exist for most popular
languages (C, Perl, PHP, Python, etc.).  You have your choice of the
litter, there.  And while none have the utter simplicity of fP's language,
just about all over much more low-level flexibility and power.  It's not
for everyone, I grant that.  But for those that aren't afraid to sink even
some minimal time into learning enough of another language, it really isn't
hard at all.  

SQL is a wee bit different from fP's methodology, to be sure.  But fPSQL
should prove that the gap is not insurmountable.

> 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

While I'm certainly in no position to -know-, my guess would be the usual
suspect--pet projects and principal interests.  Either the company or one of
the principles probably needed (or wanted) Biometrics for something of
their own, it got done, and it was marketed heavily as an afterthought to
offset the R&D.  Pure speculation, but that wouldn't surprise me.  Look at
some of the past owners--healthcare companies that wanted it strictly for
their own pet--the medical billing system.

> 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

In theory, you should actually be able to work mouseability into your
applications without going GUI.  If that's all people wanted, things like
gpm with ncurses have proven that you can integrate it.  With the raw I/O
commands, you should be able to read the desired port--same as people do
touchscreen integration with fP.  And most of the touchscreen stuff
emulates a mouse anyway.  If that was the primary goal of GI, it was
overkill.

I personally always thought GUI was a huge mistake and time/resource-sink,
but I think we've already established that.

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

They'd be far better off if they listened to their customers and planned
accordingly.  I don't want to be harsh either, particularly, but I'd
possibly go so far as "planned" in general.  It seems like someone painting
in broad strokes with a wide brush--they have the general concept, but the
end result lacks definition and isn't polished, and you don't get a
cohesive picture--in this case, of where they're headed.

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

Can you define "atomic-level HTML command set" for me in plain English?
I'm not grasping your meaning there.  Other than that...

Hey, if it's working for you, so much the better, and nobody can take that
away from you, or from filePro.  It's not to say the product has no success
stories.  The problem is that not everyone has been as fortunate as you
have, and even those that have in the past have hit brick walls at varying
points that forced them to make the hard call.

I don't advocate switching for the sake of switching.  I think there's
enough potential there to keep going.  I simply think it needs new
direction to get where (I think) it should be headed.  My personal vision
isn't by any means the One True Vision.  I'd never claim that.  I'm
arrogant sometimes, but I'm not -that- far gone. :) I'm just saying I think
it's the best target -I- can personally see for which they could aim, given
what they have and where they could go.

What could really be a boon for their revenue stream is selling support for
say, a version 6 that actually does some of the things we're putting forth.
Not just classes and conferences, but something more along the lines of Red
Hat's support (except they should actually -deliver- the support, not just
charge for it, like RH is currently doing, near as I can figure).  They
could have people helping people migrate upwards, accelerating the process
in exchange for compensation.  With knowledgeable support staff, this could
be another profit centre.

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

Customers are a big one.  Large beaurocracies appear to be another, whether
they be intra-company between divisions, or between on agency and the
organisations they do business with--particularly if the latter is a
government agency at any level.  You -cannot- get those people to budge an
inch.  I was -literally- on the phone with someone at a company (private,
not government) and they actually needed to put it to committee for
approval to change the target IP# of the ftp site they've been using for
years when the target address changed.  You run into things like that and
just wonder how anyone gets -anything- done at all.  I feel -so- sorry for
people that have to work under those kinds of conditions.  I think I'd last
all of about 2 minutes--maybe 5, tops--before either going thermal and
quitting, or getting myself sacked for just doing things on my own
initiative in that kind of scenario.  I just couldn't take it.  But all too
many people have to deal with it on a daily basis.  I don't want to think
about the amount of antacid's that they probably can't even write off on an
expense report.  :-/

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

They never should have caved and used an MS-specific library to do the job.
Same reason VALVE has Half-Life servers on linux but lost out on the
client/UI end of the game there--they used Microsoft Foundation Classes as
a shortcut in their case, and no such creature or port thereof exists in
the *nix world.  It was the same type of tactical error for the long-term,
even if it accelerated the release of the Windows version--it may very well
have doomed the *nix version to never being released.

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

Well, there are ways to carefully migrate step by step with no loss of
productivity, but the more involved your infrastructure, the more of a
rat's nest of confusion the whole process becomes.  It can get really
intricate.  Having heard from you what Nexus does, and how things have
to operate, I can fully understand a firm intention to keep the present
infrastructure in place.  And there's no reason -not- to, as long as it's
working for you, which it is.  It's the people for whom the bell tolls that
I worry about.

> I think bugfixes should come out *immediately*. I think minor level

Amen.

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

Quarterly updates would be a good start on minor level releases.

I agree with the rest of your opinions there, which pretty much echo my
initial sentiments.

> 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

>From what I've heard, it's like a giant black hole.  You feed them in, and
nothing ever passes back out the event horizon.  The wishlist, from what
I've been able to piece together from talking to people, appears for all
intents and purposes to be a PR stunt to placate the natives.  I don't
think they do more than pay the concept lip service.  They don't even -run-
it themselves--Howie was kind enough to do it -for- them.  What does that
tell you?  It tells me they don't take it seriously.  The fact that they
don't have their own mailing list (to my knowledge...and I've had some
verification from clients) for paying customers speaks volumes.  Macromedia
does for ColdFusion, for instance.  

There's a rift between company and community.  We're fortunate enough to
have Ken's presence here, as well as Ron's, and Ryan's in the past.  But by
and large, they disavow this as anything resembling official channels, and
the only official channels segregate customer input.  There's no synergy
there where people can give helpful feedback (assuming they want to listen
anyway), and unless people bring it here, nobody knows what experiences one
has had with any given issue.  Compared to many communities out there, this
is one of the more isolated companies from their user base, as far as
communications go.

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

I'd like to know, definitively, -who- exactly is in charge of reading,
evaluating, and forwarding wishlist items up the chain of command to the
people making the decisions.  Nobody--not even some advisory council
members--seems to know the answer to that question.

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

A bit drastic, don't you think?  Kind of over the top, pardon the pun.  :)

In all seriusness, I'm glad it's working for you, and for everyone it's
working for.  If it worked that smoothly and uniformly for everyone, I'd
not be saying a peep.  But there are just roadblocks, and fP is perfectly
suited to some environments, but only a "close match" for others--perhaps
one of the best matches out there, but it needs a bit of stretching with
some really ugly kludges at times to actually get what you need done.  The
people for whom it works well are already set.  That's kind of...I mean,
it's -good-, don't get me wrong.  But you don't really have to address
what's right, you have to address what's still lacking.

What's really unpleasant are the cases where fP -has- been sufficient in
the past, even with some workrounds, but then suddenly 'x' department of
inefficiency institutes a new demand, and it simply can't be done in fP.
It's a road to instant obscelesence, and it's usually not IT's fault in
most cases.  Usually it's a situation derived from non-techs higher up the
ladder who have -no- clue what they're doing, but simply mandat It Shall Be
Done.  In an ideal world, they'd listen to their IT folks--or better yet,
rethink stupid ideas in the first place.  Unfortunatly, it's far from an
ideal world.

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

I'm not necessarily saying it'll be easy to code.  But Ken's said in the
past that the code is pretty modular to begin with.  If they can get it to
the point where they actually have fP working the same with the native fP
as a driver rather than part of the core, then they're halfway there.  Then
it's a matter of releasing drivers as fast as they can.

To the fP developer, it should mostly be transparent.  A lookup might need
some additional fields for authentication, unless they're taken from
reserved variables, etc.  But I think they proved with ODBC that it's
possible ot do this sort of thing--at least to some extent.  It's the
followthrough and full monty implementation that would be the real coup de
grace.

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

Barring fresh sales due to the catch-22 situation?

Venture capital.  :-/  Not easy to come by in this economic climate, and
with a track record that hasn't exacty been great lately.

New leadership has also generally been a key to bringing about change.

Sometimes the two come bundled together.  HP sure did an about-face after
bringing in Carly to shake things up and turn them around.  Traditionally,
changing directions in an effort to put past mistakes to rest and move
onward in a better direction has not been particularly healthy for the
people who were at the helm during the period in question.

You want the unvarnished, non-PC answer?  Flat-out, fP-Tech needs someone
at the helm who has the product, company, and moreover the users' best
interests at heart, rather than their own personal agendas, pet projects,
designs for control for the sake of making sure it won't go away, and what
have you.  I've heard multiple people say flat-out that they believe the
past and current leadership at the company has been and continues to be a
problem, as well.  And hell no, I am -not- going to be naming names.  I can
and will say it's come from more than five independant sources though.  If
the community and company were a government and populace respectively, I
wouldn't bet -against- a coup given what I've heard, let's put it that way
and leave it at that.

Get someone in there with a clear-cut vision of what needs to happen, who
is also willing to put the needs and desires of the users in front, and who
can lay out a roadmap for progress over the short, medium, and long hauls,
and you might get a shot at some VC.  With the current lack of direction,
I doubt it.  Mercy infusions would be the best way to describe what they
might get in the current situation, IMHO.

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

Well...years back, there was marketability in their feature set, and from
what people have caught me up on the history of SCC's marketing, it was
less than stellar then as well--but it at least existed.

Problem is, I see it as a Moebius loop.  I don't at all dispute the
import of good advertising, getting the word out, and growing the user
base.  The problem is a chicken/egg scenario.  The marketplace has evolved
beyond the point where there would be much awe resulting from adverts of
fP's current feature set.  It's still probably the best character based
kit out there, but given some of the baggage and the apparent lack of
direction, anyone doing their homework before buying woud probably beg
off.  Hence, you need to develop further and extend the feature set to make
it more attractive so that marketing is viable in the sense of return on
investment.  Unfortunately, to afford that, you really need to get it in
front of more people to generate the revenue necessary to do so.  Rinse,
repeat.

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

I'd say it's been more like 6-7.  ODBC alone was the last 4 or so.  They
gave Jumpstart/Gold a shot for a few years before that.  And if we really
want to torture Laura (sorry, Ma'am), they screwed the pooch by abandoning
their win16 port back in 1993, even though they were sellig beta's of it at
the class I attended.  I'd say the last decade hasn't been particularly
kind.

They've been lucky, and something has always shaken loose.  The real
question is how long that luck can hold in the face of what, on the face of
it, appears to be bad decision after bad decision.  If it's not been
marketing (the recent "bordering-on-spam" campaign to anyone that's even
registered to download a demo, even if they never did has gotten ludicrous
at points), it's been whomever has been in charge of product direction.
It's a tragedy of errors, because instead of discussing where it should go
and could be, we -should- be discussing how we're already there and how
great it all is, with plans for world conquest or other such grandiose
schemes as the overtly successful often are wont to do.  :)

> It's never too late...

True, but luck does run out.  Something I try not to think about too much
myself. :) Presumably there've been buyouts and investment injections for
reasons.  While I'm not privy to the details, it's only common sense that
one does not give up control in exchange for a cash infusion if one has
a choice.  That's what it looked like from the outside, anyway.  There's
not only the matter of how many times one can go to a well, but how many
good wells you can tap into.  There's a limit somewhere, and a point of
diminishing returns beyond which no sane investor will dare to tread--at
least not without demanding a complete overhaul, stem to stern.

> 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

That -is- a shame.  I never really liked Morrison as he didn't do much for
me, but Ray Manzurek is a really talented guy--bordering on musical genius,
I'd go so far to say.

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

This -is- the company that had filing cabinets full of paperwork circa 1993
and didn't even appear to use their own database internally for things they
should have been, John. 

But back to your idea, it's actually a good one.  Some logistical problems
with that though.  Ongoing support, for one.  Accounting issues change and
require re-coding methodologies.  Seen that before.  Even assuming you pull
together a "coalition of the willing"  (*chuckle* sorry, it slipped out!),
the issues of who bears the burden of support for the actual application as
opposed to filePro itself, who is responsible for required maintenance,
upgrades, etc...all sounds iike a logistical morass from which one could
have a very hard time climing out.

Good idea, but I surely wouldn't envy the person trying to coordinate such
a project and its attendant negotiations and delegations.

Of course, I bet you're thinking that I suggest wholesale changes to the
fP engine and say it's trivial, but let a little thing like logistics
of your plan stop me. :) It's a difference between what seems like a
straightforward logical development progression, and...well, something that
involves politics and wrangling for position, etc.  I'm not trying to be
negative about the idea--I think it's a worthwhile one.  I'm just saying I
think it could present more headaches for those potentially involved than
immediately meet the eye.

Dear me.  I did trim like -everything- you quoted of mine and it -still-
ended up longer.  Okay, I'll try to keep my next one under 150 lines
before JPR smacks me with a 5.25 FH HDD or something.  :)

Geez...ten after six in the morning.  I'm for bed so I can get up and work
this afternoon and be worth a damn while doing it.  I'm too tired to even
proof my usual 5-10 times.  

Have a good day, folks!

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