Feasibility Study for Potential fP Software - Part #3 (final
for the day)
Jay R. Ashworth
jra at baylink.com
Sat Sep 16 14:25:34 PDT 2006
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_
More information about the Filepro-list
mailing list