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"
