Feasibility Study for Potential fP Software - Part #3 (final for the day)

[Jay R. Ashworth]

On Sat, Sep 16, 2006 at 03:01:39PM -0400, Fairlight wrote:
> > What *I* am thinking is that it seems like it would be a helluva lot
> > easier, not to mentio more productive -- on the assumption that someone
> > has a paying customer for it -- to just wave money in fpTech's face,
> > and get ODBC-client wired into the Unix runtime tools.
> 
> Except ODBC sucks? :)

Yes, but it sucks uniformly across all platforms. :-)

Really: pick the DBMS interface of your choice.

>                        I've used UnixODBC...when I developed FairPay for
> PayPal IPN processing and it was the only way to talk to MSSQL.  It's slow
> as molasses, Jay.  I mean -really- slow.  It was explained to me that
> ODBC is really like two abstraction layers away from what actually needs
> to be done, which adds a lot of overhead and drags performance.  That,
> and the ODBC cursor is -REALLY- evil.  It certainly had a problem with
> multiple query handles concurrently when I used it.  That said, you're
> likely correct about reusing standards.  Of course it took them five years
> to do the Win32 version of fPODBC, and they used someone else's library to
> boot--which, I gather, is why they can't just roll it into *nix.  Sorry,
> but I'm not banking on the company that added a spell checker to a database
> as a major release feature to add clustering anytime soon.  It's not a
> slam, IMHO, it's realism.  It's opinion based on their past actions, which
> speak volumes.  I could be wrong, but I don't think I am.

No, you're missing my point: *they* don't *have* to add clustering.

PostGres has that already.

They just need to weld the right shaped plug onto the bottom.

> > Then you can leverage Other People's Code to get the ACID right, and
> > you don't have to wake up at 3am to calls from lawyers.
> 
> You had to mention lawyers, didn't you?  :)  That right there always puts
> me off a bit.  :(

My intention.

*My* boss, if you can believe this, wants to get into the PBX business.

*Hospitality*.

> > Efficiency is doing the job right.
> > 
> > Effectiveness is doing the right job.
> 
> No argument.  The question is whether fP is actually doing the job right
> currently.  Some of the stuff Keith suggested goes beyond clustering fP
> in its current state of handling transactions, all the way to ACID.  I
> don't think you can hit ACID even under fPODBC, can you?  Does it support
> multiple changes on the remote end and a final transaction commit?

I would expect that ODBC, being what it is (a least common denominator
wrapper around ANSI SQL), would permit full transaction semantics, yes;
whether you could reasonably access that from filePro syntax remains to
be seen.

> I mean, in a way it makes sense that it should, but since it doesn't even
> internally support it (you can't do a series of partial lookups and then
> one MASTERWRITE, or the like), it doesn't make a lot of sense to expect
> they supported something just for ODBC that they don't regularly handle.

My approach would be "if there's an untagged CLOSE statement in the
table, or *exactly one* WRITE statement, then assume that from the
beginning of input processing to that point is a transaction,and treat
it as such."  That'd probably cover 85% of situations.

> The salient point is whether such a project should actually stick with fP's
> current precision, or try to expand upon it.  In a way, I agree
> transactions should be added--but that's something best done inside the
> engine, not tacked in...and we all know that.  Now, can we deliver what it
> already does?  Possibly.  With a lot of work.  Although when we start
> talking about maintaining system maintained fields as well, I'm suddenly a
> lot less confident about many of the models I was considering.  And a lot
> of the external models, even partial-external models suddenly look like
> they'd take a huge performance hit unless one rewrote a clone of fP's data
> storage and retrieval layer.

Hmmm...

> Let's just assume there's a way around that.  The question is still whether
> or not fP should be extended, or just coupled.  Is it done "right"?  You'll
> get two answers to that; yes, for the job it's designed to do--and no, it
> doesn't meet with higher standards set by newer software.  And Keith's
> answer touched on a lot of technical points that seem to indicate extension
> is desirable, "...while one is at it," as it were.  I both agree and
> disagree.  I'll suspend firm opinion until I read more.
> 
> > I know this isn't the category of answer you were looking for, Mark,
> > but you knew I was going to give it to you anyway, right?  ;-)
> 
> Actually, I went into this discussion with no expectations other than the
> likelihood that Smitty will give me a hard time somewhere along the way.  :)

Hee.  :-)

> I'm trying to condense the thread a bit, here.  I'm curious why the mixed
> financial viability rating from Keith.  On one hand it wouldn't be worth
> much, and on the other it would eventually be worth a lot?  That seemed a
> bit contradictory.  Unless it's based on initial vs mature.  As I see it,
> you can't really screw around with something like this--it's going to have
> to be right as possible straight off or it's not worth having.

Certainly; his point was likely that deployment would be a slow road,
though it might sell well over time.

> Let's be frank, here...  -IF- I could pull off such a venture, we're
> talking months of development and testing.  We're also talking about
> something that vastly impacts scalability.  I was thinking mid 4-digits as
> a minimum.  Say $5k.  That's more than a lot of fP installations alone, and
> you -still- have to buy each copy of filePro.  But it's only numbers like
> that which would really make it viable, as the volume isn't there, period.

For your approach?  Or mine?

> It's a small niche within a small niche.  I'm not saying it's a hard and
> fast bare minimum, but it's about what came to mind for any kind of
> enterprise based solution in -my- mind, given the kind of functionality it
> could bring.  If numbers in that range aren't viable, I'm not sure it's
> worth doing for general consumption.  This needs to be about realism on
> both sides; is it worth doing in and of itself?  Yes.  Is it financially
> viable as a time/cost investment for return?  Unless the numbers are fairly
> high, no.  I think you could -easily- eat $10k in custom development costs
> before coming even close, and that's -not- at top-of-the-food-chain
> programmer rates.  It's obviously not a trivial project.  I wouldn't expect
> the compensation to be trivial--especially without high volume, in a
> specialised marketplace.  Now, is my thinking way off-base, or am I
> thinking reasonably?

Well, I suspect that depends a *lot* on how much fpTech could leverage
the mods they had to make to d* to talk to the winODBC library they're
using.  If they could use most of that code, and drop it atop a Linux
library (suite), then all you'd have to write/adapt would be that
library.  A knowledgeable programmer, writing a wrapper library for
PgSQL that looks like an ODBC library?  A week; maybe two.

> Which is rather like putting the cart before the horse--ideally one has a
> product first before one decides pricing.  Of course, the flip side is that
> you don't invest thousands in R&D without a guaranteed return that's far
> higher.  So while it feels very much like talking about vaporware (at this
> stage it -is- all hypothetical), it's necessary to think that way to see if
> it's even worth planning out fully, much less starting in earnest.

Indeed.

> > 	"That's women for you; you divorce them, and 10 years later,
> > 	  they stop having sex with you."  -- Jennifer Crusie; _Fast_Women_
> 
> I find it's a bigger problem when you break up with them and then 2 months
> later, they start.  :)

Hmmm... hadn't thought about that.   :-)
-- j
-- 
Jay R. Ashworth                                                jra at baylink.com
Designer                          Baylink                             RFC 2100
Ashworth & Associates        The Things I Think                        '87 e24
St Petersburg FL USA      http://baylink.pitas.com             +1 727 647 1274

	"That's women for you; you divorce them, and 10 years later,
	  they stop having sex with you."  -- Jennifer Crusie; _Fast_Women_