Boy, those mouse cursors sure can cause a lot of problems can't they?
David Brennan.
DB Solutions.
----- Original Message -----
From: "Paul Heinz" <[EMAIL PROTECTED]>
To: "Multiple recipients of list delphi" <[EMAIL PROTECTED]>
Sent: Friday, September 15, 2000 2:28 PM
Subject: RE: [DUG]: How to stop mouse cursor from changing
> Max spaketh:
> > > Paul or Max, care to comment?
> >
> > Never being one to shy away from giving an opinion I'll give one now 8-)
> >
> > IBO's main issues are to do with the fundimental design decisions that
> > Jason Wharton made during the development. Paul and I were helping with
> > the debugging during these stages, and Paul has some talks with Jason at
> > one of the US BorCon's.
> >
> > Jason's environment is 100MB ethernet local area networks. So IBO is
> > subtly tilted towards a high bandwith environment, and some of the trade
> > offs in the code do cause some pain when dealing with modem links for
> > example.
>
> Yup. Essentially, Jason's component designs used to be predicated around
> lots of round trips to the server, especially when dealing with grids. In
> his component design, every grid line would involve round trips to the
> server since you are editing it 'live' albeit within a transaction.
>
> As you can imagine, this can start to hammer your network bandwidth. Also,
> this involves lots of repeated statement preparation, which means the
server
> is doing lots of work parsing and optimising your SQL expressions
repeatedly
> which ends up being more traffic than the data itself commonly. Not an
> efficient design.
>
> Jason (at that time) didn't seem to see why people would want to do
> 3-tier/ClientDataSet style batched updates for minimal SQL traffic. Nor
did
> he see the point of statement handle cacheing to avoid the repeated SQL
> parsing hit.
>
> i.e. consider a bunch of lines where various fields are commonly NULL on
say
> 50% of the lines. You will need to construct a SQL statement to perform
the
> update (or your components will be doing it for you - it makes no
> difference). Thus, you'll be preparing a query for each line which either
> says 'WHERE FIELD = :PARAM' or which say 'WHERE FIELD IS NULL'.
>
> Without some form of statement cacheing (i.e. where you keep the prepared
> statements around using a LRU cache or similar), you're doing lots of
round
> trips to the server submitting your statements to get a prepared statement
> which you can slot your parameters into and then submit to the server.
>
> Jason didn't see any of this as a problem since he works in a 100Mbs LAN
> environment and doesn't really 'believe' in 3-tier. He prefers _all_ the
> business rules to be in the server, even the ones which calculates
> extensions on lines. In his problem domain, it's a fine solution but in
> others...
>
> Things may be different _now_ of course. we don't follow IBObjects
anymore.
>
> > Apart from that the main issues that people have is Jason's insistence
on
> > replacing all the standard data-aware controls with his own vesions
(where
> > has you heard that before 8-) that he has designed to work well with SQL
> > backends . It too a long time (and a large code dump from Profax) before
> > Jason got into doing TDataset stuff, and this caused more mutterings
> > amongst the natives.
>
> Yup. Jason's position back then was that TDatasets weren't necessary -
he'd
> just provide his own implementation of all the Edit controls. As I tried
to
> explain to him, that locked his users out of using all the 3rd party
> controls so if IBObjects was to be practical as a replacement for the BDE
> (the market he intended to aim at), he'd need to duplicate the popular 3rd
> party controls as well (eg. InfoPower) or convince 3rd party vendors to
> build IBObjects based versions.
>
> Also, when building his own controls, he took the normal DB aware
component
> design, but connected to IB components, in the processg 'inheriting' all
the
> broken bits of the data aware model we'd told him about which could have
> been fixed. <sigh>
>
> He also felt TDatasets were hard and cryptic to write and didn't have the
> time to learn all the ins-and-outs since he had a real job with real users
> and real applications to finish. So I gave Jason copies of our TDataset
code
> to help him understand the design since we'd already written our own
> TDatasets for various things.
>
> Jason started building IB TDatasets but brought over some of the same
design
> biases as before so Max and Ian went and built our own direct-to-IB
> TDatasets for our own applications based on the very bottom parts of IBOs
> plumbing and replacing the bits of the design we felt were flawed.
>
> I also pointed out to Jason that if he didn't build IB TDatasets, someone
> else would (we already had) and IBO could struggle to make headway against
> such a component set. And lo and behold, FIB (Free IB Components) was
> released by Greg Deatz much to Jason's ire.
>
> > So if you do IBO you're buying into Jason's controls, component design
> > ideas and connectivity design. Some of it is good, but some rubs people
> > the wrong way. And Jason's insistence that he's Open Source by using his
> > "trustware license" is also adds a rather odd twist to the saga, and not
a
> > few flame wars 8-)
>
> Ugh.. let's not go there!
>
> > With the birth of IBX the data-aware linking, native Delphi control
people
> > are happy, but soon find that IBX needs a lot more development effort
into
> > it to make it have the equivalent functionality as IBO.
>
> Yep. Both slightly flawed but in different ways :-)
>
> IBO is more 'production' quality than IBX but I expect IBX will improve
over
> time as developers 'scratch' their itch :-)
>
> Jason has tried to discourage people from working on IBX, rather to focus
on
> improving IBO but it's _not_ Open Source (TM) but rather more like the
QPL
> (free for 'free' projects, non-free for commercial projects).
>
> Jason in his more intemperate moments has made vague noises about 'taking
> action' against people who add features to IBX which he feels are 'copied'
> from IBO. As you can imagine,
> making these sorts of 'patent-like' intellectual property claims in an
Open
> Source project doesn't win you many friends.
>
> Whether IBX or IBO will 'win' in the end or whether they'll 'co-exist' -
who
> knows?Evolutionary speaking, they occupy the exact same 'ecological' niche
> so it's going to be 'interesting' to see which outcompetes the other by
> attracting developer talent.
>
> Of course, the only way to be truly happy is to build your own - we didn't
> regret building our own IB TDatasets, but we're wierd that way :-)
>
> TTFN,
> Paul.
>
>
> --------------------------------------------------------------------------
-
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
> To UnSub, send email to: [EMAIL PROTECTED]
> with body of "unsubscribe delphi"
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
To UnSub, send email to: [EMAIL PROTECTED]
with body of "unsubscribe delphi"
