Re: Moving away from app-centric mimetypes (e.g. kword)

I'm no kernel hacker (not really a hacker at all, for
that matter), but perhaps we're discussing too broad a
class of problems.  Perhaps we can start from an
example and work outward?

The recipe idea is a very good candidate - as it
incorporates searching, simple notes, and hopefully
interaction with the web, other users, etc.

> For instance, using recipes as an example... I might
> want to present the 
> documents grouped by ingredient, by ethnicity, OR by
> the appropriate wine 
> that goes with it. The same file might appear in
> more than one place if 
> appropriate (just as we currently use links).

Let me add a few more things to the recipe example,
and I'll ask you all to abstract it back to code
design level:

+ getting data from the network:
	I'll almost certainly want to be able to include a
recipe search in my recipe archive, and my search
should work alongside the ones I have, with an easy
way to write sync data down into my local filesystem.

+ adding relationships with other data.  
	For example, I often compare similar recipes to
determine how much the proportions vary from one to
another, or to determine how the flavors are put
together.  Suppose I want to add "mango really worked
nicely in beet salad".  A note is OK, but it really my
recipe-file should notice that for oranges, papayas,
etc.  We need to establish relationships that are
vague at first, and become more concrete with
successive use.  In a previous post I yapped about
having the OS recording which files were launched in
succession.  I see this as the same idea - being
launched at the same time is a vague relationship -
more use add more and clearer (more specific)
relationships.

Of course these may be above what we can accomplish,
but if we can work them into the OS' notion of data
storage, we'll have moved way ahead.

Cheers,

EE

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com