Re: thoughts on a component architecture

[Michael Meeks <michael helixcode com>]

Hi James,

On Sat, 24 Jun 2000, James Vandenberg wrote:
> The problem that MS OLE and OpenDoc was designed to solve was that of
> getting, say, A spreadsheets data into a word processor. Mostly the problem
> was solved by 'embedding' the application into the document. ie, the
> spreadsheet would be started when the wordprocessor came across some spread
> data. The problem with this is that you need the ss already installed, and
> alternative ss programs aren't able to cope. An entire app is loaded to
> edit some small amount of data.

	Well, you need something installed to view a certain type ( eg.
Spreadsheet ) of data. Also, perhaps this 'not got it installed' thing is
due to non-free software ? Either way we share your desire for small fast
components that are omnipresent. As for alternative ss programs not
coping, they should be able to do so fine with the current framework.

> What I was thinking of doing involved having standard kinds of objects, and
> have well defined meanings for each component. The primary paradigm would
> be data manipulators manipulating data objects. Essentially the
> manipulators transform data objects, and pass them to other manipulators.

	I find it difficult to think of a suitable abstract 'manipulator'
interface to do an arbitrary manipulation.

> An example: A SQLQuery object is passed to a DatabaseQuery manipulator,
> which returns a table object, which in turn could be passed to a
> spreadsheet object which calls a function manip on all the rows in the
> sheet, passes it to a drawing object, which creates a SVG Object, which is
> passed to a standard SVGView object, which displays a map, with the data
> all put on a map.

	Well; this scenario is extremely feasible in the current setup,
all that needs doing is a little code creating to find components with
suitable interfaces to interact as you specify and then to activate the
implementations and plug the references together. I agree however that the
more standard, useful interfaces we create the better.

> Also Data objects might be passed to a network 'pinboard' so that, say,
> Mary in graphic design can put her new logo on the pinboard, replacing the
> one already there, and all documents using it would be updated. It would
> solve the problem of : "Could you put it on the network and I'll try to put
> it in to the letter before I send it ... "

	This is a rather different issue I think. A nice idea.

> Obviously this needs work, but I think it would be a lot more flexible and
> less likely to cause component explosions (millions of nearly identical
> components such as spreadsheets that differ only by file format)

	I don't see this happening; people tend to just write gnumeric IO
plugins.

> Essentially what I wanted was some way structured data could be passed 
> between compenents without each knowing about the other, and having 
> the GUI components as standard targets for data. ie, you can send any 
> SVG data object to a Vector View object, no matter what it's source. 

	This sort of abstraction is indeed nice; what needs defining is
the generic interface that a Vector View object exports. Then it merely
plugs into what we have already surely ?

> What do you all think?

	I think that Bonobo + some extra, well defined interfaces and
standard implementations solves all your design goals.

	Regards,

		Michael.

-- 
 mmeeks@gnu.org  <><, Pseudo Engineer, itinerant idiot