[cap-talk] Selling capabilities programming

[Jörg Bornschein]

Jonathan S. Shapiro schrieb:

Hello,

> The issue of configuration information is trickier than it looks.
> Assume, for a moment, that we have a means to save this type of state. A
> week from now, when the bundle is re-installed, how do we know to
> associate it with this configuration information?
> 
> Worse, a week from now when a second bundle appears for installation, we
> will want to "preserve" the configuration information by reading and
> transforming the configuration information of the earlier version into
> configuration information that is appropriate for the new version. How
> do we know what configuration data to associate? The bundle in our hands
> may be the next version of the app or it may not; the problem is that
> the installer has no way to know that.
> 
> One solution may be to declare that all such configuration information
> is publicly readable.

I was thinking in terms of a additional indirection:

On the one hand, there is a repository of installed applications (their 
constructors) without any configuration storage attached.

On the other hand, each user has his own repository storing 
"application-starter-objects" which bind (application_constructor, 
configuration_storage, other_storage) to a clickable application.
Where other_storage is e.g. your mp3 music container.


This means a user has to import an application into his personal 
application namespace. He could do so multiple times using different 
storages.

This does not solve the problem, but maybe helps to structure this 
discussion... Upgrading an application now means two things:

1) Install a new constructor into the application repository
  No problem at all

2) Import a new "application-starter-object" into the users namespace.
  There are multiple sane ways to do this:

  1. Make a new starter-object without any migrated storage
  2. Export and reimport all storage data and assign it to the new
     starter-object. Potentially using COW.
     This should never affect the old version since the new version is
     working on its very own storage objects. I think this is the
     case you thought of when saying "publicly readable"?
  3. Assign the new starter-object the very same storage objects the
     old version uses. This of course is only possible if the old and
     the new version are compatible.

I don't see a "always the right think to do" solution -- the desired 
case heavily depends on the type of application (e.g. system services, 
mail servers etc.  may prefer 3.) and the kind of storage.

Maybe the system should keep track of different kinds of storage objects 
-- this should allow good, explicit user interfaces.
(User can assign a music-storage to different music players,
  Administrator can assign Mailbox-storage to imap server etc.. )

   j.