Hi folks, I thought this post from the Interbase Objects list (from the IBO author) would be of interest to some who haven't yet been drawn into the "gotta be MS SQL Server" realm <g>. For reference, IBX is the "standard" direct-Interbase access components which are currently bundled with Delphi. ------- Forwarded Message Follows ------- From: "Jason Wharton" <[EMAIL PROTECTED]> To: "_IBOLIST" <[EMAIL PROTECTED]> Subject: IBX vs. IBO Date sent: Thu, 6 Apr 2000 09:52:24 -0700 Send reply to: [EMAIL PROTECTED] I was recently asked to give my viewpoints on this subject so I thought I'd share my biased and most optimistic views in favor of IBO... --- Product Maturity: IBO is well over three years old as a commercial product. It has thousands of developers using it and it has been in a very fast paced mode of development for its first three years. Feedback cycles are very tight and short as I quickly enhance, build and fix whatever is necessary to meet my customer's demands. Not in a few months but usually days or hours. With releases on almost a daily basis, IBO has grown and solidified very rapidly. IBO is now in the usability focus stage where the core is deemed solid and in need of little attention. I am primarily working on peripheral aspects to make the product easier to use like component editor enhancements, better documentation, etc. IBO is mature in both the solidity and feature coverage aspects. Now for the fun parts! IBX's development mode is hampered in numerous ways. It has only been feasible to get new releases out with Delphi patches since it was wrenched into the core Delphi packages. For the most part it has fallen into the development mode of a single person working behind closed doors with a little bit of help via newsgroups pointing out bugs, etc. But, in general, very difficult to tighten up the feedback cycles under a once every few months release cycle. Team B member Jeff Overcash has stepped up in his spare time to assist in the absence of the person who was working on IBX for Inprise so its development is not quite at a standstill right now. IBX lacks numerous features and capabilities I think should be required of an application development model and is in need of a lot of work to get there. This means severe growing pains are ahead. The solidity of a product that needs to grow is irrelevant because growth generally compromises stability for a certain period of time to work the kinks out. Especially when it wasn't planned growth where significant reworking needs to be done. IBX has some parts that really need this but they are core issues that may never be touched. Simply stated, IBX is very immature compared to IBO. Technical: IBX has significant architectural flaws that impose quirky behaviors and restrictions on what you can do with its datasets. These factors alone justify IBX being an unacceptable product for serious application development. Trouble is, most developers are so far into their projects before they are discovered that they suffer through them thinking a trivial fix will resolve it in time. But, this is not true. Major changes would be necessary and this won't happen soon. IBX needs a rewrite, right out of the gate. Greg (who is a good programmer) quickly (in a few months) put some code together to get something afloat in the open source realm and then a newbie to Delphi in InterBase took it over. It was a great start and a brilliant effort considering the time it was accomplished in but it wasn't ready to be forged into prime time. Because of this origin IBX lacks the professional, commercial level of quality that I think this niche demands. Technically, IBX is significantly lacking. IBO has been designed from the ground up to have a flexible architecture that delivers good performance for a full mixture of dataset operations. No irritating quirks or limitations. All of IBO's dataset operations (which far exceed IBX) are fully integrated to work in cooperation with each other. IBO's core is built upon a pure client/server oriented architecture and is custom tailored to deliver optimum performance and efficiency while at the same time providing all of the necessary higher level services and abstractions to make application development smooth and robust. At some point I need to enumerate all the features that IBO has that IBX doesn't and all of IBX's oddities and quirks. I hesitate to enumerate them because I haven't been keeping up with IBX stringently over the past few months and some changes could be in effect. I think the conceptual understanding of this issue is sufficient as most people will see the details for themselves if they know to look. Migrating BDE based apps: IBX only covers a small portion of the BDE's functionality vested in the TDatabase, TTable and TQuery components. It requires a lot of changes in property names, behaviors of methods named the same are different and in many cases it delivers worse performance than the BDE. Many things need to be added or reworked in order to convert to IBX. In short, it's a rough road to travel. IBO covers 99% of all the BDE's functionality vested in TDatabase, TTable and TQuery. It has been designed to require only minimal changes to the existing application in order to fully convert over. The only significant changes are dropping the TUpdateSQL objects out and moving the InsertSQL, ModifySQL and DeleteSQL property values into the TIBODataset component directly. Most all applications should readily convert over to IBO with little changes required. IBO has a very detailed conversion guide that explains each step very well. All differences are clearly documented in full disclosure. No significant gotchas await you. There is even two practice runs that you can take to get the feel of just how easy it is to convert over. IBO even corrects the quirks and odd behaviors of the BDE like not being able to refresh a TQuery and the inserted rows disappearing upon posting them, etc. Product Features: IBX is mainly built for use within the TDataset realm and has just about nothing else but bare bone API wrapping functionality outside of it. This is good if you are just writing a simple little gizmo app that has no ruffles or breadth. IBO also covers the TDataset realm and implements the TDataset functionality 100%. What is really cool about IBO is that it has a completely separate data access layer which parallels the VCL data access layer but it is custom tailored to InterBase for optimal client/server applications. It comes with its own custom (I call them native) suite of visual controls, grids, button bars, dialogs, etc. as well as a few form base classes that make for a great start towards a pure client/server application framework. All of these controls have a rich, high level of functionality that is integrated throughout for very rapid application development. (Yes, there is a bit of a learning curve but the investment is well worth it and is getting easier as I focus more on usability.) IBO's native components and controls are like the InfoPower of the client/server model. IBO boasts many productivity features that are in no other product. In fact, most people that migrate into IBO end up going all the way into the native side of things. I'm hoping that this native data access layer with the rich controls, framework, etc. will take the LINUX application development community by storm! On top of there being a whole suite of native components and controls, IBO also has some additional capabilities which distinguish it that should be mentioned: Fully ISQL compatible script component Totally thread-safe event alerter component Data export capabilities to XML, ACSII and DBF (with more to follow) IB to IB data pump that boasts excellent features and performance. (Easily migrate to IB6 now!) An excellent SQL trace monitor that shows PLANs, ROWS AFFECTED, performance timings, application performance only impacted when active, and more. Dataset synchronization is built- in at all applicable scopes, even between two separate users apps. Configure it easily by setting switches or handle custom situations with a few lines of code. Internet HTML generation components (TIBODatasetTableProducer) Complete transaction control Much more... Product Documentation: IBX has little if any documentation available and there is only one sample application that is just a rehash of the MastApp sample application in Delphi. It has some rehash help text from the VCL's help text but that is about it. IBO has a substantial amount of documentation. There is a general help file which contains numerous general issues, kind of like a FAQ, that anticipate all of the typical questions a new developer will ask, or want to ask. It also has numerous How To articles that spell out how to accomplish common tasks in IBO. There are more planned and in active development right now. There is also a very large help file (6MB with no graphics) that covers all of the units, classes, components, types, routines, properties, methods, events, tasks, etc. in the entire suite of IBO components and controls. These too are kept up to date and are under active improvement right along with development. IBO has sample applications that cover just about every feature of the whole library. They are chuck full of commented sources and each has an accompanying RTF file with helpful commentary on the sample, its purpose and focus. I also have a tech writer hired to compose a Getting Started Guide for IBO that should be a very professional work. IBO's sales revenue has allowed me to afford some really great talent and I'm looking forward to the results in the next month or two. Product Support: IBO's strongest aspect I believe is in level of support that its developers receive. This has been the lifeblood of IBO and the reason that it excels in all other aspects. I try to make sure that I answer all people's emails as soon as possible and I generally attend to issues that people bring to light as quickly as possible. My customers are well cared for. Depending on how well prepared a persons request is, I can fix a bug and have a new sub-release out in the same day. This is a fairly typical experience for people. It is also typical that other developers in the community (many of them have been using IBO for over two years now) answer the support requests before I can get to them. People in need tend to be buried in help in the IBO community. Source changes that come in from the community are reviewed and implemented quickly into the main source tree of IBO as well. I insure that other people's changes are not going to compromise the overall solidity and default behavior of the product. I don't know how much support is out there for IBX. It looks like there is some activity in the newsgroups but not near as much as IBO's list server. I suppose over time as more people get familiar with it there will be more community players for IBX like there is with IBO. But, the difference is, I can do something about issues if code changes need to be made and other people can't for IBX. Open source could change some of this but then perhaps chaos will reign unless IBX gets a full-time dedicated person to ensure that the community isn't going to make a mess of things. It will be interesting to see how it goes. Product Future: IBO and IBX's future both appear to be bright. By default most people will try to make do with IBX since it is Inprise's sanctioned Delphi components for InterBase. Regardless of how lacking IBX is, there will be enough people doing simple things that IBX will be adequate for them. It will be around unless for some reason InterBase decides that it should be merged into IBO under a licensing agreement of some sort. IBO could kill IBX the same way that IBX killed FIB... Because I solely own IBO I can say that it is here to stay and have the power to enforce that. I have purposely kept my options open with IBO mainly to protect my customers investment in it. I have a very solid dedication to my customers and because of this there is a powerfully strong and dedicated community surrounding IBO. This will not go away. Over 90% of the necessary investments to establish a product such as this are all in place. There is no reason for it to go away as long as there is integrity in the industry and my "trustware" licensing concept is a success. Even though IBX is free and vendor provided IBO is positioned wisely and should compete very well. IBO as a business entity isn't financially encumbered at all and I don't need to make all that much with it to make it worth my while. Although, the more the better as I plan to return much of it to the product's betterment. IBO is free to use for everyone who is non-commercial and/or contributing assistance. As such, there is no reason that IBO won't enjoy the same snowball effects that an open source product enjoys. It has been enjoying the benefits of the "open source" trustware model for three years already. I don't foresee any open source endeavor snuffing out the life of IBO. I think the only threat to IBO's future is people's ignorance of and indifference towards trying IBO out and developers using it commercially without paying commercial licensing and/or not contributing to the product either. I think there are enough people with integrity in the global marketplace to make things work. If not, then we will have bigger problems to worry about. Peace and integrity are inseparable! ---- I do not guarantee the accuracy of this information. If anyone feels that I have misrepresented anything please promptly make your concerns known in response to this posting. Regards, Jason Wharton CPS - Mesa AZ http://www.ibobjects.com cheers, peter ============================================ Peter Hyde, WebCentre and SPIS, Christchurch, New Zealand * Web automation for online periodicals: http://TurboPress.com * TurboNote: http://TurboPress.com/tbnote.htm -- small, FREE and very handy --------------------------------------------------------------------------- New Zealand Delphi Users group - Offtopic List - [EMAIL PROTECTED] Website: http://www.delphi.org.nz
