Wanted Features

[Therx]

Thought it would be cool if there was a thread where everyone could post a summary of new features they are putting in their OS or features they would like.

I'll get the ball rolling...

HSP - Hardware Sharing Protocol
[0] Allows the user to share any device on the system.
[0] The user can map remote devices to local virtual paths.
[0] The user can restrict who has access to different resources.
[0] Runs transparently under the device manager.
eg. (with my device manager)
@<PCname>/hd0/fat/documents
could be mapped to
/docs/
just as a local folder :hd0/fat/documents could be
[0] As far as implementation goes I'm not sure yet but so that it can fit in with other network protocols it will probally run over IP (HSP/IP)

If a moderator likes the idea of this thread maybe it could become a sticky?

[soap]

After stumbling across some books on capability based systems at my uni's science library I ended up deciding that it was an idea worth stealing, and ditched all of my previous code in order to do a complete rewrite.

Capabilities provide a security mechanism where a program has only the access rights that it needs to complete the task at hand. No more, and certainly no less.

There's a nice overview of capabilities at:

http://www.eros-os.org/essays/capintro.html

And a bunch of interesting related articles at:

http://www.cap-lore.com/CapTheory/

[distantvoices]

I have read this document. capability means what one is able to do. I don't know wether this term originates in the year 1966 and from the two pals mentioned in that doc. I consider it a possibilityto be implemented in an other attempt of writing an os - when I ve learned how to walk, then I can run.

what is new and what not, I do not know. I intend to build a microkernel, which handles both messages and semaphores. I don't want to become locked up with "featuritis". It is always good for a man's health to know where his Limits are.

what could be interesting: the features of apple hfs+ added to ext2 or reiserfs. this would rock.

stay safe.

[Therx]

Saw this in another thread and thought it was quite a cool idea so I'll add a summary here:-

Ability to use:-

Code: Select all

FILE *f = fopen("ftp://www.myos.org/mission.html","rwb");

[0] DOS/Win : Multiple roots
[0] *ix : Single VFS
[0] A user isn't scared of an http:// address. Nor ftp:// nor file:// nor anything:// else.
[0] Lots of VFS each is separated by the protcol (file, http, ftp etc)
[0] Transparent. Application doesn't whats local or not but properties of a file such as 'bool remote()' and 'int cost()' might help applications make sensible adaptive behaviour. But these wouldn't be nessasary.
[0] Ability to have plug ins for other protocols(eg sftp://)
[0] Apps would need no extra support at all.
[0] Access handled by VFS
[0] VFS might need to handle caching to speed up slow devices(eg floppy, remote files)
[0] Specialist apps still required for more advanced operations under each protocol but 99% of apps will benefit from the setup described above.

[Pype.Clicker]

i would like the OS to make applications programming easier than what actually exists, and especially allow quick reuse of software components, and simplified interactions between components / programs.

So far, this means :

• being able to name the process: a text writer application should be able to ask for the running mail application if the document is to be sent by mail, whatever the current mailing application is.
• being able for an application to better describe what kind of interactions it supports (in unix world we basically have stdin and stdout). For instance, a "table of content" generic plug-in could be used to quick-move in any document viewer provided that the viewer implements "DocumentViewer::readContent()", "DocumentViewer::contentType()" and "Scrollable::gotoRow(x)"
• being able for the user to browse those applications interfaces and to describes its own multi-applications commands (like "save everything")
• being able to access application / users preferences in an unified and efficient way: enough of config-files reading, environment variables and argument lookup. There should be one single space where config info are collected by the system and presented to the application in a key->value approach.

that's all so far.

btw: i like the idea but still thinking on the best way to keep it alive (probably nothing to be done as long as there are posts made to it

[pskyboy]

I to have thought about how tom make displaying information on my OS easier for the App developer. I was thinking along the lines of defining output and input areas which are blocks where output gets written to or input gets put into. Then using an XML file you map the various areas onto Controls for the visual interface or positions in an output line for console interface.

Peter

[Pype.Clicker]

pskyboy: i had envisionned something roughly similar i called DXI (pronounced "deexee") where an app would be able to announce (using a semantic formatting string) what kind of information it expects on its input plugs or will send on its output plugs.

Any "dxi-master" would then be able to parse the formatting string and generate automatically the dialog boxes for data feed by a user, but also to construct on-demand filters between apps ...

where it differs from xml approach is that the data stream encoding is completely binary (? la ASN-1) but could be translated in an XML stream by an automatically-generated filter (using the DXI formatting string ... )

[pskyboy]

This sounds good, it basically takes the concept of pipes to the next level in my view. What i envisage is the ability for a programer to write a piece of software with no UI but with data areas, plugs whatever we call them. Another developer could then make a nice UI and have it interact with the core software by posting its commands to one of the data areas and having results posted to another. I think this would best be implemented as a stream and so a pipe would be the perfect thing to fill this role.

This seems to be exactly what you have envisaged with DXI. You also raise the point that XML requires complex parsers which is true and one of the reasons i was wonderign wether XML was the best tool for the job. I still indeed to use XML to define a UI though as it could ver easily describe the layout of a window.

This also reminds me of another point that i was going to mention to u which comes about from your File system brainstorming thread. I plan to use XML for storing the metadata in files on my OS. This then easily allows for core meta data to be there but users and developers the ability to add there own metadata for that particular filetype without it interferring with any of the core meta data. I can then also use another xml file which will defien what way the data should be displayed to the user.

Peter

P.S. You might guess im a big XML fan

[Pype.Clicker]

P.S. You might guess im a big XML fan

This is very interresting as we seem to have similar "wanted features", but you want them with XML as i don't want to use XML internally (for religious reasons ) ... so if we both complete our job we'll be able to compare the efficience/usability, know if we were right in our choice, and we'll have only implemented the way we preferred

[Nairou]

Its funny how several people can independently come up with the same idea.

I'm working on a similar idea for my OS, separating the program from the interface. This is to greatly reduce the program size, since it doesn't bother with interface drawing (all interface input/output is handled directly by the OS). It also allows the program to be plugged into other programs like modules, simply by remapping its input/output connections.

The interface would be defined in a separate file, in some sort of markup language (maybe XML). However, the problem I'm currently tackling is with dynamic content. Interface definition files are static, so how would a program define dynamic interface elements? For example, a web browser? Or a dialog box who's options varied depending on the context?

[Pype.Clicker]

How dynamic do you want your content to be ? Why not replacing your "static" interface definition files by a more dynamic approach like

Code: Select all

plug("music-player","info").getInterface()

the interface could be generated by the provider application on plug creation (either from a resource file or built from scratch).

Code: Select all

new plug("music-player","info") {
   public void read() {
      if (playing) return PLAYING + current.author.length + current.author + current.title.length + current.title + current.album.length + current.album;
       else return STOPPED;
   }
};
plug.setInterface("playing:(author:%S,title:%S,album:%S) | stopped:()");

If you need something even more flexible (for instance because you have plug-ins for several media types, and each of them can provide different kind of information), why not just having 2 plugs: one that will announce the current interface for the other one
Or maybe just having "change interface" signal that the reader can use to re-program its filter and continue reading correctly ?