On LinuxPlanet, Kurt Pfeifle explains details about Tenor, a framework that will facilitate new ways to locate and otherwise manage content. Learn about the background of Tenor, what differentiates it from "desktop search tools" and why this new approach is needed in a world of ever growing disk space. Additionally, the article provides some insights from Scott Wheeler, one of Tenor's authors and primary designers.

"With the content browser, you will be able to find and use information spread out across your system using the same semantics you use when thinking about or describing that information in day-to-day life. It will also allow you to find and build relationships within your information set."

This is the only info I could find in the article about what specifically Tenor aims at is. It sounds much like GNOME Storage. Does Tenor have a different goals? If not, how will the actual frameworks differ? Could some of the Storage effort be reused?

Could the framework be (made) useful outside KDE (say on GNOME) and published on freedesktop.org?

AFAIU, Tenor will be able to find an image if I ask for 'an image that I got last summer as an email attachement by John', that's what makes Tenor a 'Context Link Engine' - in that case, with Tenor being part of the KDE framework, you'll receive the email with KMail and save the attached image. Tenor will register the save and try to gather the context, in that specific case it would associate the image to the email it came from, thereby also create a relation to the author of the email, the email's subject, date etc. It would also be able to extend the search following logical links, like 'all emails by John', 'all emails sent to John', 'all emails sent/ received that day' or possible hyperlinks inside that emails. Extending this to KAdressbook's geographic data, I could use the image to search for 'a website which link someone from France sent me via Jabber/ Kopete the same day I received this otherwise completely unrelated image'.

Beagle is just a 'mere' desktop search with support for metadata, similar to Apple's Spotlight - but that will only be a subset of what Tenor will do...

Gnome Dashboard was very exciting a couple of years ago but it hasn't gone anywhere since (seems interest has moved over to Beagle). From the few news items I've read, Kat/Tenor sounds like a great basis for such things and more in KDE.

And what if I receive my email through Thunderbird? Or create a letter in OpenOffice? Will that be taken into account by Tenor as well? Please make that possible!

Tenor sounds like a great idea, but I ask you, don't make it too KDE-centric. It's poor enough that Gnome and KDE have developed two VFSs, and neither of it works at a layer that makes it accessible in konsole/terminal/xterm ;) No need for two search engines which are limited to their specific desktop.

actually, Tenor is Swahili for "Big Brother". it will phone home to Scott if you live in Europe or to me if you are in North America (we still need Asian, African, South American and Oceania conspirators; applicants welcome) with all your linking secrets. All Your Tenor Are Belong To Us.

ok, seriously though. yes, there are privacy concerns and we've been talking about them at length. it's a perfectly tamable problem, but we won't see implementations of those solutions until we have the basics down first.

as for filtering out related Tenor subgraphs, we should be able to get that almost "for free" since given any starting point, it's possible to create a subgraph specific to that node with a given "radius" or specificity.

moving Tenor data between machines won't be hard; merging two meshes effectively will be an interesting task, however, as will defining boundaries of visibility.

removable media will also be a bit tricky since there is greater ambiguity in addressing ("ok, but the foobar.kwd on which CD?"). it's a problem we haven't yet gotten to solving, yet. i don't see it as insurmountable, we're just not there yet in the project is all =) it's also a problem common to all such indexing services.

Also, if not taken, I'd like to cover the Redmond position too, as well as Armdonk and Mountain View.

If you accept me, I'll start to submit a weekly "Tenor findings CVS" to this list. I am quite sure that the Microsoft/Redmond blokes will will have a close look at it. Will be interesting to see their "mesh" workss. The same for the IBM/Armdonk or Google/Mountain View.

All these big players are known for lifting off OSS technology for their won good.... So let's watch them while they are ag work.

WRT the removable media issue: This question just reminded me of how well the good old Commodore Amiga handled removable media (with floppies though). You could have a desktop icon link to any file or application, and if you clicked on it the machine asked you to enter the disk DISKNAME into any drive.

Apologies for getting a bit technical here, but I'm bad at explaining this stuff in other terms. :-)

> How will Tenor deal with parts or all of my data being moved to a different
> machine, or being stored away on a CD-ROM?

The issue of how to export subgraphs (the base of the Tenor structure is a classical "graph" in the computer science sense) is one that I've been thinking about a lot recently. It's still a few steps away, so right now it's just something that I kick around on long train rides and draw pictures in my notepad about, but it will be doable.

Actually exporting subgraphs isn't that hard -- what's hard is connecting that to the security model and being able to define or decide what is exported, how and to who. I've been putting a lot of thought into that, but if I went into it here it'd just be a lot of fuzzy technical blabbing that I'd probably change anyway, so watch this space. There will be more articles in the future that will cover the details as they become concrete.

Great stuff. It strikes me that KDE is in the almost unique position of having the technology, the development ethic and the organizational structure to accomplish such a turn-around, thanks to the tightness and code-reuse within the KDE platform. Which other player in the field could roll out such heavy-weight technology in a reasonably complete set of desktop applications at the same time - the enabling condition for being able to take advantage of contexts? Apple comes to mind, arguably, but the list pretty much ends there.

"KDE has the tightest coupling of application frameworks and applications of any desktop in existence. We can't throw as much money or as many PhD's at a problem as proprietary desktops, but we can push new ideas out in a fraction of the time that they can."

OS X is pretty close. IMHO Apple is starting with great usability and heading towards rich frameworks, while KDE starts with great frameworks and is heading towards usability.

Still, while Apple spends developer time on interfacing with users and swallowing their ego when it comes to UI development and testing, there's still too much of the "my way is the right way so frack off" in the KDE world.

While KDE folk can (and IMHO) should steal all the nicest bits of OS X UI, I'm sure there's folks at Apple who will look at KDE's cool tech with an ugly face and they'll steal those ideas and plop a great UI on them.

I just got myself a Mac Mini - mainly because I needed a multimedia capable machine that still fits around my table, and because I wanted to make music. So here's the Linux user's view on OS X.

Yes, Apple did a lot for usability. But some of the things really get on your nerves in OS X, and I'd rather say the "my way or the highway" philosophy applies for OS X far more than for KDE. In KDE, there are usually several ways to achieve some task. In OS X, there is usually just one way. There are far fewer buttons and switches in applications, and this makes it easy for a beginner to get aquainted with the app, but it really gets on my nerves when I e.g. can only have a button for left OR right rotate in iPhoto's toolbar, not both.
And Apple Mail starts downloading (caching) your whole IMAP account by default as soon as you configure it (about 800MB in my case), and cannot search in mails any more once you disable this. (Whatever is the IMAP SEARCH command for?)

So, I think somewhere there should be a middle ground. Apple has some *really* cool applications and although I miss some features in the iLife apps, they *are* good software. but the default user interface is just to ... barren ... feature wise. It's overloaded with special FX to compensate for that, though.

German speaking users, please visit my blog for a more in depth review. :-)

What number of people does "we" include? Looking at the length of the authors list of beagle it will be surely hard to finish an even more ambitious project like tenor in time for KDE 4. What part will developers of the existing applications play? What can they do or at least think about today to prepare for tenor?

i've got a whole tribe of oompa loompas in the basement working on this. scott's working on the import permits for his own oompa loompa tribe. (Germany tends to be a bit more of a stickler on these things than Canada.)

seriously though, there's a rather small number of us. and yes, the application developers will end up adding the vast bulk of value to it by building services on top of it.

things like the Content Manager will be a generic user interface to Tenor's stored information, and there will be many specific ones (e.g. annotations in pdfs and elsewhere).

we just have to have make the engine work, others will build upon that to expose the functionality. sort of like most of the rest of KDE's library-base technologies. =)

Soo. Is this something that applications would need to support specifically? Something like dashboard where applications supply "hints" as to the current context?

It sounds so interesting, partly because, when someone talks about Beagle, or Spotlight, I immediately have some idea how one could implement such a system. With Tenor, I can't even begin to think how it might work, code-wise. :)

>Is this something that applications would need to support specifically?
No, this is KDE so it's customary to let the framework handle such things:-) Something like the way KIO-Slaves work today, they are available to all KDE applications without the need for any specific handling in the applications.

> With Tenor, I can't even begin to think how it might work, code-wise.

we'll have APIs and examples for people to play with shortly.

the basic essence is that you take a piece of information, decompose it if necessary in an application-specific manner, and then feed it into Tenor along with a description of what "gos together". Tenor then builds additional relationships, if it can, and slots it into the larger mesh and allows this to be searched for and navigated through either independently or as part of a larger body.

it's quite a bit easier to show with examples, which Scott and I have put several of together. once we're happy with the way the APIs look and the storage side of it is working, we'll start releasing developer previews. it'll become pretty obvious at that point =)

there is no reason why any application couldn't fee data into it. there will likely be a Qt dependency (though not a GUI one) in the core Tenor engine, but i don't see that being a problem. i expect an IPC bridge to emerge, for instance, and if other app developers have a problem communicating with a non-gui but Qt using app then they may want to check their priorities =) personally i see this as similar to the glib issue =)

the file indexer will not be tied into the Tenor engine, but use the API like any other application. so there could be multiple indexers written for different purposes, one of which could use KFMI (or something faster and with FTI-appropriate capabilities, preferably)

and yes, it should be possible to write FireFox extensions and OOo plugins to tap into tenor, for instance.

there will also be a GUI library for KDE apps to use (stock interface elements and probably various KDE specific helper goo-gads) as well, but that should be a separate library from Tenor itself and so be of no concern to non-KDE apps.

Maybe I missed this part in the article, but... How will Tenor be implemented? Will there be a separate Tenor-app that you use, or will it end up being a KIO-slave? I could see benefits in having "tenor://seigo kde-usability png" in file-dialog for example. The example would find all png's that were sent to kde-usability by Aaron J. Seigo. yes, the example is pretty limited, but gets the idea across.

Of course, there is a problem that KDE has even today: how do we tell the users about all the great technology KDE has? I still run in to KDE-users who do not know about audiocd:// or fish://!

Well, the article is mostly speculative. I'm fundamentally an application developer (that ends up spending more than half of my time on framework components, so...) so when I explained this stuff to Kurt at one point I mostly talked in terms of what people will be able to do with this stuff.

In other words the things that Kurt mentions are the things that I've designed towards; concrete use cases, if you will. But the user visible things will come as applications start to use the framework and new tools are written to take advantage of it. I'll probably write a basic search tool to show off the possibilities and then let the interface guys have fun with it. :-)

Basically Tenor makes it easy to write a "Spotlight on steroids" -- like libkio and KHTML make it easy to throw together a basic webbrowser, but that's not what Tenor itself is.

Part of the problem with explaining some of the stuff is that it's sometimes hard to imagine how something will work when there's nothing popular to really compare it to. Most of the stuff that people think of is a subset of what Tenor makes possible.

>Of course, there is a problem that KDE has even today: how do we tell the users >about all the great technology KDE has? I still run in to KDE-users who do not >know about audiocd:// or fish://!

I guess I am one of them. When I paste audiocd:// into the location bar on Konqueror, I get a dialogue "Malformed URL audiocd://" The same applies to fish://.

In my protocols config dialog, I have "fish" and it's checked, "audiocd" is missing. I am running kde3.4. Where is the documentation on these protocols? Doing a google search brings up so much information not so useful to a n00b like me. Thanx.

That did it, thanx! While I know what ftp:// and http:// or https:// can be used for, I wonder what use could be made of fish://. Since I have no system setup for the fish protocol, could you point me to one? Cb..

That's what's great about fish://, there's no setup, your linux machines are already fish servers (as long as they run an SSH server, which almost all do). For any Linux or Unix machine you have a username, simply use fish://username@machinename to access the filesystem of that machine using that username. Unfortunately, it doesn't work for Windows machines, for that you have to use smb://.

I can only say wooooow! I never knew KDE has this feature and I guess I am missing a lot more. I guess I can put "fish://username@machinename" in the save dialogue to save a file on this machine if everything is setup. This kind of publicity is what we need for KDE. When I get back to the Linux box at home I will try it out! Thanx. What other exciting protocols/goodies are there to exploit?

My only grip about KIO is that tar, rar, etc should be implemented as pipes or something like that. I mean, it should be possible to view a TAR file from a FTP. Dunno if this is being worked on. My suggestion for how the url would look like is something like this: scp://server.com/file.tar|tar .

Anyway, yes, KIO is one of the best piece of software that lives in KDE. Really useful.

It would be great except that somebody might use anchors named tar: in their html file, and even possibly name their html file with a .tar extension. It would be hard to figure out what was meant in every situation.