[unios] Re: Generic design. More comments

[Anders Petersson]

From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

At 03:56 1998-12-15 , you wrote:
>From: Pieter Dumon <Pieter.Dumon@rug.ac.be>
>
>> 
>> From: Anders Petersson <anders.petersson@mbox320.swipnet.se>

>> 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... :-)

Let me take an example of how OH's would work:
When a function in an interface of an object is called by another object
that has been granted access, the following happens. The OH that implements
the interface for the type of objects that the current one belongs to is
called, with the caller's parameters and the OID of the called object. The
OH does whatever needs to be done, like fetching the objects data from its
own (the OH's) storage, and then returns the result to the caller...
For the caller it looks like he talks to the object, when he in fact talks
to an OH.
If the object can - logically - be represented in several ways (like text,
that can be shown as formatted or pure text), the OH can say that the
object supports both interfaces. Both interfaces point to the same OH, but
different entry points of course. If now only the OH implements stripping
of formatting tags, clients can access the text, even if they do not
support formatted text.

An Object Handler is an object too... all OH's share one interface, with
commands (mainly for use by the system) that has to do with its function.

Access to an object is considered for every supported interface. Compare
this to the rather unflexible read/write/execute access types on UNIX.

>> 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.

Yes, other OS'es does this... in fact very much of what I want is already
done - only that it's not done together before. This is unavoidable.

>> * 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.

Could be so... but if every use of objects, the way they communicate and
their distribution 
are well-defined, this should be made easier.

>> 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!

I don't know anything about that, but it's not impossible it's already done.

>> 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.

Great. Good is good; good and fast is better. :)

binEng

------------------------------------------------------------------------
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