Bulldog ODBC for filePro

[Fairlight]

On Tue, Mar 08, 2005 at 11:53:52PM -0500, Jay Ashworth, the prominent pundit,
witicized:
> > Jay, don't be...<impolite verbiage omitted>.  Please.
> 
> I wasn't *being* one of those.  Really.  :-)

Okay, I retract.  :)

> What we've been asking for for ages is an ODBC server (why can't
> *anyone* just *call* them clients and servers, so we don't have to
> guess?) implementation that will let live clients talk to active
> filePro data file sets.  

Sure.  Of course, that's going to take a substantial amount of time, and
I'm not sure that it's even compatible with fP's data model--IF one can be
written as an external.  It certainly wouldn't be trigger-friendly in the
conventional sense, as an external.

> You may have gotten something different out of the website, but I've

Well, it helps talking to the developer, as well.

> You didn't read my other reply, I think.  As near as I can determine,
> "this going over well" is defined as "letting a whole bunch of filePro
> sites pull their data out and move it over to 'something easier to use'".
> 
> Certainly what's posted about it so far gives, rather than corrects,
> that opinion.

Why, WHY do so many assume, the second you supply interoperability in one
direction, that the product is being abandoned?  I know someone that's
running a web site using OneGate, MySQL with a good dose of PHP and
Java--and it's all driven from filePro -exporting- data out to MySQL.  But
filePro is at the core of it, even if the web site itself is using the
MySQL very heavily with the data that's been -exported- from filePro.

They didn't replace it.  They didn't drop fP.  They augmented their
solution quite heavily to deliver a really -slick- experience.  I've seen a
first-hand demonstration of such a solution, and I was impressed with how
seamless it was, and the flow involved in making it all work.  And fP is
right at the centre.

I will never understand the shortsightedness inherent in saying that if you
let data flow only in one direction, you may as well drop the product.
That's patently untrue.

Has it ever crossed your mind that people might need to access the data
from multiple sources, and Access (like it or not) may be "better" for some
people?  That's a real need for them, whether you and I agree with it or
not.  And this product can fill that need.

> It's positioning, Mark.  Convince me that I've misread what he's trying
> to enable people to do, and I'll change my outlook.

You're reading it in black and white absolute (and very narrow) terms.  If
the data goes one way, you only see it as a migration.  You apparently
overlook the whole prospect of augmentation.

> Fine, you start with release 1.0.  But if your description of 1.0
> amounts to "look: here's a tool to let you yank your data out and use
> it somewhere more comfortable", then how would you *expect* me to
> react?

Like it's useful for what needs it can fulfill--which are more varied than
you're considering.

> And my only investment is 15 years worth of code...

And nobody's holding a gun to your head forcing you to give up that
investment.  

> And, as I say: I don't see anything that explains how Ryan views his
> roadmap for the product.  He may well plan to make it into a full
> server-side implementation.  But I can't tell.  Do you really think it
> wouldn't have been a good idea to put that in the posting here, even if
> he didn't say it on the website?  I mean, c'mon: I know Ryan's been on
> this list for a while; I can't imagine he isn't at least a *little*
> tapped in to the zeitgesit on this topic or he wouldn't be writing the
> damned thing in the first place.

Let's see...  You go out and program something like this, you have no
concrete (even if you have solid speculation) idea how the marketplace will
take to it, and you think it's a good idea to announce future versions
without knowing what the actual reaction to initial release is?  How much
time, exactly, is one supposed to sink into something that may or may
not fly?  This community is a remarkably hard sell for anything--even if
there's a need for it.  Half the time, developers need things they don't
even know they need.  When they're exposed to something, 95% of the time
they don't recognise it for what it can do for them even when they're given
the specs.  More than 75% of the time, a visual demonstration appears to be
necessary to drive home even the fact that something is what they've been
looking for, nevermind the cases where they didn't know they could benefit
from it.

So if someone sank a few hundred hours into a project (I have no idea
what's all involved...it can't be trivial though), I think they should
probably have the benefit of reaction to v1.0 before committing to anything
else.

> Clearly, as I say, you read the product's goal in liff differently
> than I do. I'd be obliged if you could point me to what you based that
> viewpoint on?

I base it on a far broader interpretation of its potential uses.
Interoperability--even in only one direction--does NOT necessarily mean
migration.  And I would think you'd know (and recognise) that fact.
Apparently I was mistaken in that assumption.

Even -if- your assumptions are/were right, you could have simply -asked-
him if he's planning on expanding it, or what his development plans are.
But nope, you just aim a .50 cal Gatling at his tail rudder and pull the
trigger with a few inane comments that won't help you (or anyone else)
learn a thing.  The only time you came close to "asking" anything was in
your reply to my response to your terse dousing with cold water--the
originals of which served no purpose except to see yourself type, AFAICT.

mark->
-- 
          *****   Fairlight Consulting's Software Solutions   *****
OneGate Universal CGI Gateway:                  http://onegate.fairlite.com/
FairPay PayPal Integration Kit:                 http://fairpay.fairlite.com/
RawQuery B2B HTTP[S] Client & CGI Debugger:     http://rawquery.fairlite.com/
Lightmail Mail Sending Agent:                   http://lightmail.fairlite.com/