so people are starting to grok the concept of what managing your files and other data will look like with tenor. but there's another interesting side to tenor that probably isn't of much interest to most users, though it will have benefits for them. to me it's one of the more interesting sides of the project, really.
an obvious problem on the desktop is managing files, so to date everyone has attacked that problem. current desktop search solutions tend to concentrate on files. from the demos i've seen, Spotlight steps out side those boundaries somewhat and extends itself to things like the control panels. and this is really the right direction.
because the problem with finding files is just one manifestation of the larger problem. it's the one that the most people can empathize with quickly, but it's one of many similar issues.
the real challenge facing the desktop is managing large mountains of information in a more human(e) way. control panels represent a huge amount of information; so do the applications you have installed on your disk; so do your addressbook contacts; so do application interfaces; so do your projects.
taking that last example, it would be very nice if there was a simple way to just "pile" up bits and pieces of information that you are working on together. some applications do have the concept of "projects" and if you are very careful you can create projects using directory hierarchies.
but application-centric projects fall down as soon as you leave the scope of the application. for instance, KDevelop has an extensive concept of a "project" and yet you can't add the spec doc PDF to your project in KDevelop in a meangingful way. sure, you can pop the file in there, but it just sits there inert and KDevelop has no way of knowing why its there or what its supposed to be used for.
using on-disk hierarchies, things rapidly fall apart when you wish to switch from one project to another or when you have items that belong to multiple projects. a couple years ago i was talking with some KDE users about how they work when viewed from the concept of "projects". it's just so much work right now to manage it properly; applications, web site, files, emails, schedules.... and then in January i spoke to a fellow attending TPOSSCON in Hawaii and he reiterated the exact same needs. they still weren't being met. =/
with a contextual linkage engine, however, it is easy to "throw" a website into a project alongside PDFs, application shortcuts, and more. these items don't have to move anywhere on disk, they just become related.
here's a trivial example: i used to play nethack a bit. it's a fun game. but keeping track of all the goodies you can get and what they do meant either having a really great memory, or consulting a reference guide. i found such a thing in the form of a set of HTML pages. i also had some scripts i'd run that would periodically "back up" my saved game just in case ;) so before i'd start playing, i'd open a couple web browser windows and load up the reference guide. then i'd start playing, and periodically run my scripts from another xterm. not much fun to set up playing. but with a proper concept of "project", could simply have made a "nethack project" and in that pile would be the websites, the scripts and a link to the nethack binary itself.
how would you do that today? manually.
how will you do that with tenor? by throwing related objects together into a named pile and accessing them later.
projects are just one example, but it's a good one to show the difference between a "search engine" and a "contextual linkage engine". the latter is a tool to build with. of course, users probably won't know nor care that this cool projects concept is only possible because of contextual linkage.
now, it's interesting to note that there are programs that do provide the ability to create piles of objects. basKet, for instance. and they are a lot of work to get going and get right, and they are pretty much standalone. and to make them truly expressive is even more work. a contextual linkage engine makes these sorts of application easy to create and immensely expressive. because, remember, you'll be able to do searches through these project piles as well.
there's an app on OS X called QuickSilver that would also be fairly easy to implement by building on top of tenor. and so on...
... and don't even get me started on the possibilities of networking multiple tenor instances together. (that's a couple years off i think, so i'm trying not to get too distracted ;)
i really don't know all the things that will be possible with tenor. but i do know that one of the fundamental challenge points on the desktop that we see just about everywhere we look is the inability to create relationships between arbitrary (to the computer) things in a way that the computer can then build representations for.
oh yeah, and you can do full text searches. heh.