Re: app-encapsulation and transparent-install (MS is doing it)

[Felix Bellaby <felix pooh u-net com>]

David Jeske replied to one of my CORBA ramblings with:
 >> Using CORBA to implement the document model in GNOME should mean
 >> that you can transfer a document to another user without worrying
 >> about whether they have the software to manipulate it. CORBA will
 >> organise their local environment to accomodate the document 
 >> automatically. AFAIK the CORBA services spec does not describe
 >> mechanisms for freeing resources when services are no longer
 >> required. However, the services that it does describe could maintain
 >> reference counts and access times to support garbage collection.
 > 
 > That sounds good. How does that work for non-document oriented
 > applications? For example, a game. Or, how does that work when someone
 > wants to create the document type, but dosn't have an existing document.

What I am describing here is how the CORBAservices spec suggests that
object systems should be implemented. Under this model it would be
possible to attempt to activate arbitrary objects at arbitrary
locations. These objects might be documents, games or some other kind 
of "object". The creation of new objects and moving of existing ones 
are both handled by the same combination of services. Once you have a
way to describe what you want to the trading service it does the rest.

 > Is this something which is taken directly from the standard CORBA
 > services specification? Has anyone ever implemented this system
 > before?
[clip]
 > I am not aware of a system which uses the CORBA model yet, and as they
 > say, the "proof is in the pudding". Last time I looked at the CORBA
 > services specification it was a buch of 'well thoughtout design' which
 > nobody had ever implemented.

There's the rub (o:

There have been various moves towards implementing parts of the CORBA
model but AFAIK no one has gone out and done the whole lot. The Naming
service is already being implemented in ORBit and it looks like the
Event service is also on the cards in the short term (useful for
linking document data). There are free implementations of parts of the 
LifeCycle and Externalisation services within Fresco (which uses CORBA 
externalisation to save arbitrary GUI elements). A good record of
what is going on in the commercial world is at the flashy OMG wesbite.

However, as you say, the CORBAservices spec does include a lot of 
'well thoughtout design' that is freely available. One of the big 
problems facing gnome is how to design the baboon document model idl
interfaces. The guys at OMG have already put years of work into trying 
to specify idl services that would support the basics of a distributed 
document model. Implementing the CORBA idl might well be easier than
trying to design our own. 

I am not brave enough to believe that GNOME can do a better job
than OMG or that any other new approach would have a better chance of 
working. OMG have a lot more experience with designing object models 
than the rest of us. After all, we are doing what they say in the 
CORBA2.2 spec and parts of that have yet to become well tested 
technology.
 
It may well be more difficult to implement the CORBA model than to
reproduce some existing implemention (like MS OLE). However, since we
do not have the sources to any of these models trying to implement any 
of them will be a pain. The fact that MS OLE works (sort of) is by no
means a guarantee that we will have much luck reproducing it. 

CORBA has the tremendous merit of approaching everything from an extreme
abstraction (like K&R did when designing UNIX around C streams). 
Models developed by commerce tend to bolt on new pieces that work 
for now but create disasters in the future.

GNOME is starting from scratch with a view to capturing the future.
CORBA is in a similar position. Why not hitch a ride?

Felix