RE: APIs, messaging

[Jeff Lowery <jlowery@scenicsoft.com>]

> How about that the object-centric pet shop sends you a pig 
> that responds
> to being petted, fed, etc. as you expect, while the 
> data-centric pet shop
> sends you a book about how pigs respond to stimuli, or a 
> stuffed, dead,
> pig :-)

Well, I think this pig's been beat to death. 

Getting back to reality, sometimes I just want a bit of data, maybe munge it
a little within certain constraints you've explained, and hand it back to
you. Now, if I'm doing come radical munging, or initiating processes similar
to those you're already implemented, I want the whole, live, squealing
beast. 

So you don't know what I want to begin with; the response seems to be to
give me everything so I want of nothing. Fine, except I incur costs of
transport,  warehousing, and operation that are sometimes out of line from
the really useful bits that I'm looking for.

So the solution is to cut the suit (suite?) to fit. It means defining
classes in a more intelligent (IMO) way: Define the data structure, define
the constraints, define the methods, define the processes, define the
architecture. This is not a radical approach. Such is done everyday with
database-centric applications. It's costly now, becuase most DB's are
relational, and class types and object containments are, well, hierarchical.

Note that this doesn't slight OODBMS's or ORDMBS's in any way. I think it
actually helps both, since it tears us away from supporting binary data
types and formats, or at least gives us an easier, more explicit way of
defining the translations of one model and one representatino to another.

Is this an oversimplification? God, yes. It seems a plausible vision,
though, at least to some poor souls.