[unios] Re: Generic design. More comments

[Pieter Dumon]

From: Pieter Dumon <Pieter.Dumon@rug.ac.be>

> 
> From: Anders Petersson <anders.petersson@mbox320.swipnet.se>
> 
> The point is that settings that are of public interest are made into
> objects. Authorized objects can view and change them. It's much like
> configuration files...

Understood.

> I think I've failed to explain OH's good enough... it's more generic and
> flexible than anything else I know about. I'll see if I can clarify when I
> know a little more exactly _what_ to clarify.

I think that would clear things up for me... :-)

> Not? OK, I'll give some examples.
> * Use compressed data just as ordinary directory structures, since the OH
> for compressed data can make it all transparent.

Ok, winNT and Unix do it too.

> * Transparent networking makes remote systems look like just another part
> of the system tree, allowing you to do everything remotely, without any
> need for FTP or rlogin or any other special tool.

Samba does it too.

> * Functions can be replaced easily and have a system-wide effect. Have all
> tree structure windows in a GUI replaced at once, or upgrade all text
> windows without any need for applications to care about it.

Ah, nice. That's something we could use.

> * Have files with intricated data structures show their contents as a
> sub-tree in the system tree, and in some cases have the contents changeable
> the same way as everything else, without the *need* to use the app's
> interface.

Nice too.

> * Flexibility... you want to add support for a new device? Plug it in,
> write an OH for it (like a device driver...) giving it some interfaces (or
> define your own interface if nothing existing fits), and create an object
> (runtime) that maps to the physical device. Then you're done. The system
> takes care of accessibility/security and sharing (allowing the modes you
> say are possible).

Great !

> * Another flexibility example. To move to a new GUI, install it in the
> system tree and redirect all related object types to the new OH's. With
> also all OH's in the systree, it's no problem to distinguish which object
> types to redirect. If now only the new GUI uses the same interfaces - which
> should not be a limit, since the interfaces would be strictly logical for
> their purpose and generally needed - applications will run just as happy
> under the new GUI. Or why not let different GUI's live and act in different
> branches of the system tree. The principle of locality makes them happily
> coexist.

Could work, but in my own experience, "upgrading" or changing some modules
and certainly not a whole UI is not simple. Murphy is always around
somewhere.


> It looks like there's a general move towards MFC among Windows
> applications.

Aargghhh!

> If you implement something that is useful in more than one app, you can let
> everybody that codes for the OS take advantage of it... yes, DLL's do that
> too, but by using interfaces, others can even find the new possibilities by
> simply looking at what the objects can do (the supported interfaces and
> their functions), and use them directly throu the scripting language. If
> the new features conforms to standard interfaces, other applications will
> know how to use them, without upgrades.

Hm, sounds like JavaBeans!

> This is my approach. Lift out common code from the applications and shared
> libraries, and make them availible, understandable and exchangable in the
> whole system. Not as fast, but more space-efficient, flexibile and
> worked-throu implementations (since only done in one place). It also makes
> common code less subject to language-specific implementations.

Of course, this is something very basic that should be really implemented.
I think it can be made fast too.
 
 
> On the other hand, isn't everything we ever say just what we think? ;)

:-)

Pieter


 
----------------------------------------
 Pieter.Dumon@rug.ac.be               
                                      
 http://studwww.rug.ac.be/~pdumon     
 
 ICQ  : 12428974
---------------------------------------

------------------------------------------------------------------------
To unsubscribe from this mailing list, or to change your subscription
to digest, go to the ONElist web site, at http://www.onelist.com and
select the User Center link from the menu bar on the left.
------------------------------------------------------------------------
UniOS Group
http://members.xoom.com/unios