Citát Jesse Ross <[EMAIL PROTECTED]>:

<snip>

> > But of course for some data (like images, or sound), we can push that.
> Probably providing a
> > simple framework + associated bundles for the components themselves...
> so an app will
> > just use the framework, which in turn will load and run the bundles.
> Adding
> > components will just consist in adding new bundles to the system.
> 
> Exactly. Developers wouldn't make applications anymore, they would think
> in terms of "what type of tool could I provide for manipulating data?".
> It's the Unix philosophy applied to the desktop.
> 

No need to say more! This is exactly what a desktop environment should be:
collection of cooperating tools manipulating shared data. Idea is the same as
the unix-one, but shifted to a higher level. 

Building a complex tool in Unix is roughly connecting smaller, usualy one
purpose tools. Connection is done with pipes and redirections. Tools operate on
streams and files (also kind of streams).

Analogy

Unix -> Desktop environment
File, stream -> object
pipes and redirections -> outlets and actions
programs -> components
daemons -> active components

Where component can be substituted by: agent, actor, application, service,
script,...

In both environments you can use scripts to simplify your task. 

Unix script                   |  Desktop environment script
------------------------------+--------------------------------------
network of information flow   | network of relationships between objects
between stream processing     | (outlets) and triggers (actions)
elements called programs and  |
files.                        |
------------------------------+--------------------------------------
program execution             | message passing
------------------------------+--------------------------------------
background daemon action      | notification handling
------------------------------+--------------------------------------

and one can go on and on ...

The desktop environment does not and should not replace the Unix functionality
completely. It is complementary environment with graphical interface. I can
imagine even graphical tools in the desktop environment for joining unix
programs into a flow network. Both environments can cooperate and use each
other's functionality.

However, there are several problems with this tool based approach. One of them
is current process based architecture that is greatest obstacle because it
directly supports application based model. We can not replace it, at least not
now, therefore we have to live with it... But how can we have this tool based
environment with current application oriented system? Is that doable? If yes,
how and what hacks are needed so the user feels like in the tool based
environment?

By the way: anyone remembers old adventure games? The screen was divided into
two: scene view and inventory view with collected objects and commands. One was
able to take a hammer from the inventory view and try to hit any object in the
scene view... One was able to take a gold ring and give it to an old woman to
get a magical potion... Why can not be the desktop environment similar to that?
;-)

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

Reply via email to