🚀 go-pugleaf

Mike Pinkerton wrote:
>In article <AF75597B-CEA29@205.149.171.109>, "Jeff Moore"
><jcm10@dreaming.com> wrote:
>>The focus of JavaBeans is _developer_ oriented components that can be
>>strung together using a builder tool to build an application. Beans don't
>>necesarily have UI or storage (well beans are serializable, but that isn't
>>the same as OpenDoc's concept of storage).
>>
>>The focus of OpenDoc is _end-user_ oriented components that can be strung
>>together by the end user in a compound document. Parts have to have UI and
>>storage.
>
>I think this is the best way to summarize the differences between OD and
>Beans, if you're looking for a 100-words-or-less description to tell the
>boss. Both are trying to solve similiar problems but from opposite ends of
>the spectrum, hence the hesitance from the Beans group to want to roll in
>the "monolithicness" of OpenDoc (that just hits me as so ironic).

Unfortunately, I think the fact that they're trying to solve similar (or
the same) problem tends to get lost precisely because they're tackling
it from opposite ends.

Components are just real world objects, in bit-form, on a network.  If
they're from the world of a developer (compiler, string comparison
routine, list box, etc.), then they'll be used primarily by a developer.
If they're from the world of a user (invoice, account, customer, etc.),
then they'll be used primarily by a user.

But never forget that they're the same thing.  Nothing prevents a user
from sending messages to a listbox, and likewise, nothing prevents a
developer from sending messages (for extending its functionality, for
example) to an invoice.  They're all just objects on a network.

Now if only we can get the infrastructure creators to recognize this.
Hopefully, this is what IBM's Blue Beans is all about.

MB
--
Mark Baker; mbaker@nortel.ca distobj@acm.org
Northern Telecom     Ottawa, Ontario, CANADA