Hello again,
Last my email, the email from Frederico and work with database system
inspired me to an alternative to the installer application. The
alternative is complementary and can use the application behind.
The alternative is obvious and parts of it was mentioned several times
on GNUstep lists: have handlers in workspace. Analogy: triggers in an
database system. For those who do not know how triggers work, they are
basicaly composed of a trigger action (insert, delete, update, ...)
condition for the action and a SQL code. The SQL code is executed when
the acction happens with given condition.
Workspace should be full of those triggers based on notifications.
Basically, Workspace should send a notification on any significant
action that happens.
Installation of a package:
1. user drags a .pkg into */Library/Packages
2. WorkspaceWillCopy/WorkspaceWillMove notification is posted
3. handler recognises:
file type = .pkg,
destination = */Library/Packages
4. handler invokes any additional mechanisms required for silent
installation
5. .pkg in Packages directory is replaced by some 'receipt' marking that
there is such package installed
Deletion of a package:
1. user drags a .pkg from */Library/Packages into Trash
2. WorkspaceWillDelete notification is posted
3. handler recognises:
file type = .pkg
target = trash
4. handler invokes mechanisms, perhaps in the installer.app, to remove
the package
Deletion triggered by moving an application to trash:
1. user drags a .app from */Applications
2. WorskpaceWillDelete notification is posted
3. handler recognises:
file type = .app ,
target = trash
4. handler invokes installer app mechanisms for app removal
5. installer looks for packages where the app belongs
6. installer tells user that he is about to delete an application and
whether it should remove all app related things
Unresolved issue is: how to undelete from trash by drag and drop?
Requirements:
- everything should be transparent (no user interruption if not
necessary)
- user uses only workspace to manipulate files
- experienced users should know about those mechanisms
Frameworks/bundles/resources should have reference counting and there
should be retain/release mechanism for them, so frameworks are not
removed when they are still used by an application. The
workspace/environment manager should know about all installed frameworks
and should know whether a framework is used or not. It can be done by
explicit retain/release mechanism or from looking into all application
bundles from known places (*/Applications). The manager should not care
about misplaced applications.
This is not exactly how it should be done, it is only rough sketch which
needs to be deeper specified. For example, we will need:
- list of posted notifications
- mechanism in the environment for registering handles/observers for
those notifications
- installer framework/application
What do you think? This definitely needs to be more refined (on the
wiki?).
Regards,
Stefan Urbanek
--
http://stefan.agentfarms.net
First they ignore you, then they laugh at you, then they fight you, then
you win.
- Mahatma Gandhi
