[RFC] One ioslave to rule them all...

Hans Meine hans_meine at gmx.net
Wed Jun 29 13:09:26 BST 2005


On Tuesday 28 June 2005 20:20, Thomas Zander wrote:
> On Tue, Jun 28, 2005 at 07:06:08PM +0200, K??vin Ottens wrote:
> > But not everything though searching _only_, hence why I still claim that
> > you'll need a hierarchy.
>
> This conclusion is wrong;  just because you (and others) have not fully
> solved the problem with searching does not mean that the old system of a
> hierarchy is the only way left to go.
>
> There is much more to explore.  (document relations,  keywords based
> relations and probably stuff nobody thought of just yet).

I want to mention the Reiser Vision paper - I read a M$ .doc of it a long time 
ago, but I think it's this: http://www.namesys.com/whitepaper.html

This is Hans Reiser's vision on what he'd like reiserfs to be "in the future", 
and has definitely a lot of interesting ioslave-related ideas.  It also 
discusses the idea of hierarchical vs. attributed vs. sorted vs. ... types of 
structures / access.

> I'd like to be surprised on how user friendly v.s. powerfull you can make
> the home:// listings...
Concerning the user-visibility thing, I just want to throw in 2 cents:

- Maybe a translated location name like "Users' home folders" instead of 
"home:/" would be more enduser-friendly.  One should not forget UNIX-loving 
power users, but I don't think we run that risk on lists like this one.. ;-)

- Another disadvantage of presenting home:/ to users like "my dad" would not 
be that he asks "what's that?" - I think users will be able to cope with that 
by just ignoring some details.  However, they might want to ask "why the heck 
is home:/ a valid URL in one program but not in another?" where "another" 
could mean a windows/gnome/enlightenment/macos/3rd party prog like 
gimp,mozilla or others.  For a better user experience, I vote for showing 
mostly cross-platform URLs or such with translated prefixes (which clearly 
belong to our desktop environment).

Nice greetings,
  Hans




More information about the kde-core-devel mailing list