Filepro-list Digest, Vol 25, Issue 23

[Tyler]

>
> > Laura Brody wrote:
> > >> I can't really say what the project scope would be like, I must
> admit.
> > >> However, write access is already there in fpCGI, which makes me
> wonder
> > >> about why it isn't in fpODBC.
> > >
> > >     It is in there. End of discussion. Consider yourself corrected.
> >
> > Nope.  It's not.  I can't connect to a filePro datastore using a third
> > party app via ODBC.  End of discussion.  Consider yourself corrected.
>
> Okay, chill.  I mean, seriously...not only are you apparently confused on
> some key terminology and apparently unable to listen to a direct answer
> -and- read the introductory paragraph of the filePro ODBC product page on
> their web site (http://www.fptech.com/Products/fpodbc.shtml), but you're
> now just plain being an ass.  I'm sorry, but you're really pushing it.
> They've been polite to you through now.  After that shot, I wouldn't be
> surprised if you were sent straight to /dev/null.


We've already cleared up the difference between server and client, and that
fP only offers client.  My objection is that ODBC isn't offered as a server
protocol, and that most developers expect that from a database.  When I
think of filePro, I think of it as a db in the same category as MySQL or
Oracle, not as a development tool for authoring clients to other dbs.  I
doubt I'm alone in that.

Why is it not rude for Laura to say "End of discussion. Consider yourself
corrected." but not me?

> Until today, I wasn't even aware that Ken was responsible for filePro
> > development.  I made a comment based on what I knew, which obviously
> > wasn't much, and I said so at the time.  You took it is some kind of
> > personal attack.  Which it obviously wasn't, as I couldn't even name a
>
> Gee, MIGHT it be because she's his WIFE?  Ya know, if someone insulted my
> spouse, I'd rain seven kinds of hell down upon them, have no doubt.


As I said:  1, I didn't know who he was, 2, I didn't know who SHE was, and
3, it wasn't a deliberate insult to anyone.  I stated how it looks from the
outside, from the perspective of someone who hasn't been intimately
connected with fP, fPTech and it's developers.

> core app developer.  All I did was voice my opinion that it was either
> > lazy programmers or bad marketing strategy that was behind the lack of
>
> Yeah, I think it's the "lazy" part she had a problem with, man.  They're
> married, Ken's development lead.  *thwack!*  What did you THINK was going
> to come of a comment like that--chocolate and roses by FedEx?  :)


1, I didn't know who he was, 2, I didn't know who SHE was, and 3, it wasn't
a deliberate insult to anyone.  I stated how it looks from the outside, from
the perspective of someone who hasn't been intimately connected with fP,
fPTech and it's developers.

> ODBC server functionality, given that filePro has had plenty of time to
> > develop it and that it's a widespread standard used to communicate with
> > DB servers (which is hardly an opinion without basis, just a poorly
> > informed basis).  You countered that it was more of a problem to do with
> > inherent programming issues to the core applications, and I agreed that
> > you probably would know better than I would as fP source code and APIs
> > are closed source and I've never had any access to fpTech.  Negative is
> > not the same as nasty.  Nasty implies that I had malicious intent behind
> > my comments.  I don't.  Why would I?
>
> You sure the hell sound it.  "Consider -yourself- corrected," fired back
> at
> her?  Dude, I don't know laura -that- well, and I don't know you at all,
> but you sound like you need a life preserver real quick--'cos that ice
> you're skating on...it's getting REAL thin, REAL fast.


Again, why was it not rude for her to say it, but it was for me?  If it was
rude, I was justified in being rude back.  If it wasn't rude, then neither
was I.

And who needs knowledge of the source code to see how it doesn't fit the
> paradigm.  "IS THERE A PERSISTANT PROCESS RUNNING?"  No.  NOT A SERVER.
> "IS THE APPLICATION TIGHTLY BOUND TO THE OS?"  No.  NOT AN INTEGRATED
> SERVER.  See how easy that is?  I don't need a line of source code.  I
> just
> need to look at -how- it's run.

I'm starting to wonder if you've even -used- the product, at this point.
> If you have, you obviously haven't thought much about the topic other than
> to winge at them.


I use it every day, obviously, or would I bother posting?  And nope, I
seldom look at how it's run.  I'm using the platform to develop and maintain
code, not to develop and maintain filePro itself.  So I haven't a clue it
there's a persistent process running somewhere, to be honest - there may
very well be, somewhere.  Maintaining the server environment is not part of
my duties.

What crosses the line is something I would consider in the eye of the
> beholder in many cases.  You've crossed (or damned near crossed) it
> already, specifically with your shot above at "correcting" Laura.


<shrug> You seem to be really stuck on that.  Again, why can she say it and
not I?  If she doesn't want to talk about it further, there's better ways.
Why not just ignore that part of the message as not worth pursuing, or just
state that "that is my final position on the topic.", rather than 'feeding a
troll'?  Saying that I'm wrong and then forbidding any further discourse on
the topic is polite?

Not that Laura needs anyone to defend her.  She's -more- than capable.  :)


Er....then why have you done it three times in the last few paragraphs?

Just as an aside, I also keep pointing out that my viewpoint is that of an
outside developer who doesn't really know that much about the inner working
of fp or fpTech.  Which may not be most fP developers these days (I don't
think there's a lot of people taking classes in it at night), but is
certainly most people in general.  I'd also like to point out that almost
everyone considers a db backend to be a db server.  It's like saying a car
should run on gasoline.  Sure, you can get a hydrogen vehicle or an
electric, but it's pretty rare; when I see the word 'car' I expect to put
gas in it.  One expects a database backend to act as a server and offer ODBC
connections.  Yup, fP does say that their ODBC is client only on the
website.  That's not the issue here, as far as I'm concerned.  It's whether
or not it shoud offer it as a server, and what developers expect from a db
backend in the year 2006.  It doesn't *matter* what fP was originally
designed to do or how well it does it, or what it currently offers, really.
What matters is what people want from it, and what it needs in order to
function well in a modern IT environment.  Can I fuel my car at any gas
station, or do I have to go to a special fuel station found in only three
places in the US or build my own station everywhere I want one?  For me,
ODBC is a biggie because if I had it, a lot of other objections to fP
wouldn't matter (not just mine).  Alot of those objections seem to revolve
around the interface. With ODBC, I could use whatever interface development
kit I liked, plus I could integrate with other applications far more easily.

I think the topic's mostly been beaten to death now, anyway, especially
since I spent most of this email having to discuss interpersonal dynamics.
I gave my opinion as an outsider, Ken and Laura took issue with both the
opinion and how I expressed it.  My reasoning on why ODBC hadn't been
implemented as a server protocol for fP was examined and rebutted, and I
deferred to their informed opinion that it would be a big technical
challange to add ODBC server functionality to filePro.  My opinion remains
that it's a must have and that most developers expect it from a database
product and would think of fP in that way rather than as a development
platform with client-only ODBC, and my impression is that fPTech doesn't see
it as a cost-effective project and so it's unlikely to ever be implemented.
Fair summing up, personal issues aside?

Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.celestial.com/pipermail/filepro-list/attachments/20060207/4446cce9/attachment.html