OSDev.org

@Pype.Clicker: That's part of your DXI-concept, am I right?

The idea is great, IMHO. It actually breaks the limitation of a fixed number (3) of in/output channels, and adds structure (the channels are named and typed).

In my system design (as far as it has progressed yet), I wanted to incorporate a similar thing by allowing processes to expose objects, which could then be used to control or invoke certain services in the process, notify about events, but also act as data sources (output) or data sinks (input). I've not yet made up my mind about how an application describes the objects it exposes.

cheers Joe

so far, i've identified the need for 3 or 4 types of 'objects' that could be needed for such programs interoperations:

- input and output datastreams (such as all streams described above
- controllers objects that appears like a variable such as "MediaAmp:volume:integer(0-100)" or "MediaAmp:playing:one-of(prev,play,next,pause,stop,next)")
you have a list of values the variable can take and all you can do is giving it another value (which will usually trigger an action on the .
- status objects

In some sense, we can observe that "controllers" acts exactly like a stream that you can only write to according to a specific protocol (e.g. you know you're expected to write "=60" or "+10" but that "=Hello" will be discarded).
And status objects acts exactly like input streams that give you the value of the object as soon as you open them and that send you updates of the value later on.

What would be the advantages and disadvantages of allowing all applications to put identifiers and controls in the global namespace?

advantages are obvious to me: you can interact with any application the same way you could interact with 'shell tools'. You could grab any 'document being processed', apply filters on it, report data, create custom applications by interconnecting out-of-the-box programs, etc.

If the designer takes care to enforce both computer-readable and human-readable meaning of each 'interaction item', that means you just take your wrench cursor, grab the widget you need to and assign them shortcuts or drop them in a 'dockbar'. That also means you can easily grab the environment of a whole desktop session, and save it as a 'template' for later use.

Disadvantage are obvious too: if no proper access rights are enforced, any program could make any other programs do anything. You could, however, end with user-friendly setup if you only allow operation on child items (e.g. since my shell launched both browser and text editor, it has control on both and can build bridges between the two), plus some "extra grants" the user give to some programs (e.g. clicking with the wrench on my penguin-control-widget, catching its 'program public key' and dropping it on MediaAmp's keyring now allows the penguin to control the volume, etc).

Pype.Clicker wrote: advantages are obvious to me: you can interact with any application the same way you could interact with 'shell tools'. You could grab any 'document being processed', apply filters on it, report data, create custom applications by interconnecting out-of-the-box programs, etc.

One of the main reasons why I pushed this concept further (in the GUI realm of applications) is to encourage (or even enforce) a seperation between the UI and logic parts of an application. Just as you described above, a media player instance would expose controls for volume, play/pause, skip, song/movie title, artist, progress and lots more, of course.

The GUI should then be written seperately. It is not much more than a set of UI elements (buttons, sliders, textboxes, canvas...) which are bound to the application's status and control objects.

The advantages, IMHO: The user can quickly change the UI of an application, probably even at runtime, it should be easy for him/her to even design his/her own (without really fiddling with the app's sources). And, as Pype mentioned above, the logic part of an application can be fully controlled and observed by other applications (or by shell commands), even without ever drawing the GUI when it isn't needed.

cheers Joe

Pype.Clicker wrote: Disadvantage are obvious too: if no proper access rights are enforced, any program could make any other programs do anything. You could, however, end with user-friendly setup if you only allow operation on child items (e.g. since my shell launched both browser and text editor, it has control on both and can build bridges between the two), plus some "extra grants" the user give to some programs (e.g. clicking with the wrench on my penguin-control-widget, catching its 'program public key' and dropping it on MediaAmp's keyring now allows the penguin to control the volume, etc).

And this is why there are capabilities.

In addition, each program can expose a universal object that computes what rights another program should have to it.

This discussion reminds me of something I read recently about Microsoft's new shell:

http://arstechnica.com/guides/other/msh.ars

Sounds like they pass around streams of objects instead of untyped byte streams or text streams.

Colonel Kernel wrote: This discussion reminds me of something I read recently about Microsoft's new shell:

http://arstechnica.com/guides/other/msh.ars

Sounds like they pass around streams of objects instead of untyped byte streams or text streams.

It's a step into the right direction indeed - but there are still some things I would do differently (like everywhere ::) )

In MSH, the 'commands' must be special classes (AFAIK), and the syntax is still much too unix-like (still just one stream in and out - or has that already changed?).

I think such a shell should mostly feel like an OO script interpreter, one should be able to utilize any type of object, in MS terms: any .NET object type. For convenience, I would go with dynamic typing, and when methods are invoked, the brackets should be optional. Along with the ability to make direct references to methods, such as
it should be possible to build an environment in which one can accomplish daily work.

It has been some time since i last investigated into MSH, so please pardon me if I missed some things.

cheers Joe

JoeKayzA wrote: It has been some time since i last investigated into MSH, so please pardon me if I missed some things.

OK, I had a look at the paper now, and I have to admit that I did miss some things: now they also provide the ability to deal with .net-objects directly (invoking methods, retrieving properties...). But for me, one question remains: When we can instantiate objects and deal with them like inside a scripting interpreter, then what are the 'cmdlets' for? I mean, wouldn't it be more flexible to provide their functionality as simple methods?

And, btw, is it a bad sign to start quoting oneself? ;D

cheers Joe