ervin's piece of web

Looks like Simon Edward's [blog post about hierarchies](http://www.kdedevelopers.org/node/1332?from=10&comments_per_page=10) showed some concerns about some of our "new" ioslaves. Moreover, I've seen some similar questions raised on [the Dot](http://dot.kde.org). Since I am the maintainer of some of them (system:/, media:/, home:/ and remote:/) and participated a bit in trash:/ development (which is maintained by David Faure), I think that I should explain some more what it is all about. I disagree on the fact that people "don't get hierarchies". That's not that simple, they can deal with hierarchies if they don't become too complicated. If it's really deep that becomes a problem. That's just like lists, if the list is too long you easily get lost. On the other hand, I fully agree with the fact that "people doesn't understand other's people way of organizing things". But don't forget that those statements are particularly right for managing documents, in particular because a document can be placed in several categories. For managing documents, it becomes clear that a system based only on hierarchies is not the best solution. That can be addressed using more complex systems based on search and concept tagging. Some of the most refined systems are still "research toys" (I'm even working on one of those "toys" for my PhD). But there's still hope, and we already have technology to improve things today, that's the Tenor path. So why creating system:/? Because the current **UNIX hierarchy** is not well suited for desktop users. Lot of its content is really cryptic and exists because it's necessary to make the system work. Finally that's just a low level concept from the user point of view. Then system:/ is here to hide this **implementation detail**. Because, we had some ioslaves for a while partly helping with desktop tasks in a network enabled context : access the trash, access a medium (usb flash disk, camera, dvd, etc.) and access a remote share. All this is covered by ioslaves recently created, or existing for a while (audiocd:/, media:/, trash:/, remote:/, fish:/, ftp:/, etc.). Those **ioslaves are great from a developer point of view** because they lead to specialized components addressing one particular task. But they are not so great from the user point of view, because he has to know they exist in the first place, and he has to deal with URLs. Then system:/ is here to hide this **implementation detail**. We don't want people to deal with complicated hierarchy, or to type URLs. So I introduced a new concept in the ioslave land : forwarding. This way we keep the technical advantage of those tiny specialized components, but in the end we can have the user dealing with only **one ioslave** allowing to work on **desktop tasks**. Other ioslaves like media:/, home:/, trash:/ are now helpers for the system:/ ioslave, users don't even need to know they exist. In this case it becomes easy to avoid dealing with URLs, you just need a link to system:/ (and it's already available). We just have to make sure the system:/ hierarchy doesn't become too complicated. That's exactly why the entry list at the root of this hierarchy has been simplified for 3.5. Now the user has **system:/** which is a **hierarchy suited for desktop tasks**. One day, we'll surely go beyond hierarchies but that's not a reason to let current users with half-baked tools, that's exactly what I'm trying to change.