Re: Another idea
Ronald Vos <Egregius <at> gmail.com>
2006-01-02 22:01:07 GMT
I'm surprised noone bothered to reply yet. Probably a sign most think
it's a decent or good idea. ;)
IMHO, a modern OS should have at the very least have filehandlers. One
of the great ideas AmigaOS and BeOS used, and the other OSes are still
behind on. Extend it to protocols in general in an Object-oriented
system, and you got a component-based OS like (I think) is envisioned.
Henning Hasemann wrote:
>Err... I tend to forget attachements :-/
>
>
>
>------------------------------------------------------------------------
>
>
>At first, I dont know much about how the terms URI and URL are exactly
>definied, but I am used to use them, as probably every reader is.
>
>The old idea: files and a few other thing, everything else is exotic
>--------------------------------------------------------------------
>
>Well in the file-orientated world of unix and its clones
>(I mainly have experience with Linux) the is no real place for things like
>domains. For example it is not possible to make a symlink to a website.
>So thex invented protocol-notation like the well known http:// to give things
>that are retrieved in "strange" ways such as over the internet its own
>namespace.
>This make some things easier as the namespaces cant interfere and it reflects
>somehow the underlying hard- and software-structure.
>But that exactly is the problem: Unix tried to unify everything with its
>single-tree filesystem (see the devices nodes under /dev for example) but
>these things are still outside.
>
>But how can you merge really everything?
>----------------------------------------
>
>Things behave very differntly, for example a printer is a mostly
>write-only-device and normally you cant seek. A classical file is read- write-
>seek- and deleteable, a directory has listable contents. On a web-server there
>are lots of files you could address, but unlike to a local directory you often
>cant list its contents. And if we talk about programs, well. You can feed data
>to them and they produce data, usually with lots of side-effects.
>
>So you see all these things really havent _that_ much in common.
>But there is still one thing: They all handle data.
>
>The Approach: Protocols, Targets and Handlers
>---------------------------------------------
>
>If we take a construct like http://www.unununium.org, it is quite easy to
> interpret: Use the method "http" to retrieve the standard file from the
> server "www" inside the domain "unununium" inside the tld "org".
>I'd like the idea, that http is actually a HANDLER, i.e. a piece of software,
> that retrieves data from a given TARGET.
>So I whould think of http as the handler name, "://" as a delimiter and the
>rest as a target specification, the handler should interpret.
>
>Especially I whould call this a rightsided (pointing left) handler.
>Thats a random nomination, since I always imagine the user to sit on the left
>side of a line and receive data there, so the standard one-directional
>data-flow is from right to the left (you'll understand this sentence later).
>
>+------+ data +----------------+
>| user | <--------| http://TARGET |
>+------+ +----------------+
>
>This picture might help.
>Now you might say: "Wait, wheres the webserver that sends data to http?"
>Well its outside our scope. http contects the webserver and gets data from it
>on its own, once we gave http the target, we cant interfere with it.
>But we _could_ indeed redirect the output of http to anywhere we want.
>("user" is a fictive point here, think of the screen or so)
>
>What is it good for?
>--------------------
>
>With this model in mind, we could construct every handler we want.
>Imagine, we have a handler mp3decode which is twosided, pointing left, i.e.
>it gets data from "the right" and outputs data to "the left".
>
> +-----------+
>decoded wave data <---- | mp3decode | <------ encoded mp3 data
> +-----------+
>
>Note that this handler doesnt accepts any targets at all, since it doesnt
>receive its data itself like http. You must give data to it to receive
>anything and you (or better, the system) have to handle its output.
>
>Now think of your new sound card.
>You could say, your sound card is a handler, but that whouldnt be quite right.
>You could have multiple soundcards, so the soundcard is a TARGET and the
>handler is an abstraction to adress them. So sound://0 whould adress the first
>soundcard, sound://1 the second, and by convention sound://default a system
>default.
>Okay, what kind of handler is sound://? It receives data, but doesnt send, so
>its leftsided (receiving from the right).
>
>Okay, now imagine, you want to play a wave-file from an url directly.
>Some mp3-players do, and there whould be some tricks with pipes, but now look
>at this notation:
>
>sound://0:mp3decode:http://www.some_domain.foo/some_mp3_file.mp3
>
>Nice isnt it?
>Imagine to be able to type these things at the console.
>
>What if sou want to copy a hard-disk-partition to another machine via
>ethernet?
>
>tcp://1234:disks://a2
>
>These are simple connections.
>Data flows from one point to another, maybe getting filtered.
>At the moment this model doesnt address things like listing directory contents
>or configuring the handler at runtime.
>That would go through ioctl()s I think, the rest is just a matter of notation.
>
>Think of what that means to a complete OS:
>You can really access everything from every application!
>I could type ssh://henning <at> someserver.bar/htmlfiles/foo.html into my favourite
>web-browser and it would display a file it got via ssh.
>
>The final point is that a "display program" such as a web browser or an image
>viewer should not be limited to a set of protocols choosen at program time.
>It makes sense to limit them to a content-type indeed (how should an
> image-viewer display a wave-file?). But it should be your choice how you
>get your data.
>
>Henning Hasemann <hhasemann [at] web [dot] de>
>
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Uuu-devel mailing list
>Uuu-devel <at> unununium.org
>http://unununium.org/cgi-bin/mailman/listinfo/uuu-devel
>
>
RSS Feed