[CLUE-Tech] Re: Component Object Model - Why? was: COM and Linux

[Kevin Cullis]

Jeff,

Thanks for the insights. My friend recently told me that his Winb98 box
was running the disk access a LONG time, turns out he had a virus.  I
told him that Windows has more than 50,000 while Linux has less than 10.
He's almost ready to jump.  Now if he could just get his customers to
jump ...

Kevin

Jeffery Cann wrote:
> On Thursday 03 May 2001 08:26, Grant Johnson wrote:
> 
> > This isn't really necessary under Linux.  This is for calling and using
> > small parts of very large applications.  If the applications had been
> > done correctly in the first place, they would be already manageable
> > sizes, and this structure would not be needed.
> 
> Kevin,
> 
> In my humble opinion, Grant statement about 'applications done correctly in
> the first place...' does not describe COM accurately.  Knowing Grant, he
> probably understated his description, so my point is not to criticise his
> response, but to fill in some missing pieces that hopefully will lead to more
> understanding.
> 
> COM is about reusable software components.  It started as a technology called
> OLE - Object Linking and Embedding.  This idea allowed Microsoft programs to
> embed documents within other documents.  For example, I can take an Excel
> chart and put it in a Word document.   OLE evolved into a more generic object
> model (that includes network transparency) and is called COM - Component
> Object Model.  (BTW - Micro$oft did not invent the general idea of reusable
> software components).
> 
> The interesting aspect of OLE and later COM is that the component is not a
> standalone application (like a UNIX utility), but can be embedded within
> other programs.
> 
> The benefits of a component architecture is reusability and user consistency.
>  Different applications can share components.  For example, when I want a
> chart in my text document, I do not have to reprogram the text application to
> understand how to draw a chart.  I simply create the chart using a chart
> component.  Similarly, if I want to draw a chart in my spreadsheet, I use the
> same chart component that I used to draw it in my text document.
> 
> Both the spreadsheet  and the text application share the use of the chart
> component.  In effect, killing 2 birds with one stone.  From a QA
> perspective, you can imagine the cost savings of only testing a single chart
> component, rather than hard-coding charting twice, once in the spreadsheet
> application and once in the text application.  A side benefit is that the
> chart component looks and acts the same in the text or spreadsheet
> application.  This makes it easier for the user to use it.
> 
> KDE, for example, implements a component architecture called Kparts.  KDE
> developers were wise to use the COM idea for KDE.  A good example is the
> KHTML component.  This component is used to read, interpret, and display HTML
> documents.  It is used by the Konqueror web browser / file manager.
> 
> Suppose I am writing an HTML editor for KDE and I wish to allow my users to
> preview the HTML page they are editing.  I can use the KHTML component in my
> HTML editor and use it to preview HTML pages.  Again, 2 birds with one stone.
>  In fact, Quanta (http://quanta.sourceforge.net) uses KHTML for this purpose.
> 
> KOffice, like MS Office, uses Kparts to reuse components and build
> applications with consistent functionality quicker.  This is a much wiser
> approach to application development which has proven to be successful.
> 
> Bonbo is the GNOME implementation of the COM idea.  I am not familiar with
> Bonbo, but you can find a lot of info on Google.
> 
> Later
> Jeff
> 
> Drawing