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.
Dot Categories:
Comments
--> The article isn't very specific on Tenor's technology. It
does however hint at the main conceptual idea that drives
its development.
--> The main purpose of the articles is to provide background
on *why Tenor has been started* at all, and why I, as a *user*
(not a C++ developer) see a very convincing use case for it.
--> Tenor is now a joint project of Scott and Aaron J. Seigo,
it seems to me. (I neglected that aspect a bit in my full
article).
http://dot.kde.org/1109163846/
Scott Wheeler on desktop search
"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?
Tenor reminds me alot of gnome's beagle.
Can't wait to see how the KDE team will implement this one! It will surely be killer.
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...
your example is a good one, but tenor goes even beyond that. i just blogged about a couple of the more non-obvious possibilities tenor opens up. =)
How about a link to the blog entry, Aaron? :-)
I see only a very short mention of Kat on aseigo.blogspot, you were looking through the code and suggesting that clucene be used on 12 August.
http://aseigo.blogspot.com/2005/08/akademy-callinng-all-ohioans-kat.html
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.
http://www.nat.org/dashboard/
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.
Just expressed my hopes and wishes,
Oliver
Spotlight can do all the things you've listed.
It looks rather impressive. When will we see the first applications to make use of Tenor technology?
Regards,
James
KDE 4, likely not before. About 1++ year.
in a production quality, shipping release, yes.
we'll have demos and beta releases well before that, though =)
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?
Most people tend to use more than one machine, archive data and to buy new computers from time to time. It would be a shame to lose context data when doing so.
On the other hand, you would want to be able to drop Tenor data on your local machine and/or when giving data to others, according to your wishes. Otherwise Tenor would be a Big Brother of sorts.
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.
I volunteer for the position in of Tenor Conspirator in Cupertino.
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.
Indeed, amaroK doesn't have a solution to the removable media problem, despite it being often requested.
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.
That's something PCs still don't do half as well.
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.
Wouldn't "1++ year" be equal to two years?
Actually, it evaluates to 1 ;-)
With the promise that next time you ask the answer will be two years >:-)
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.
The KDE team did spend a lot of time in early versions getting the framework right with integration technology such as dcop, kio and kparts.
I guess they (and we users coincidentally) are now set up to reap the benefits of this extra effort.
L.
From my blog last week (http://www.kdedevelopers.org/node/view/953):
"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. :-)
Jens
Tenor sounds cool, but these are hard problems. Is there actual code in a cvs somewhere to check out and take a look?
there are earlier drafts available that reflect sketches of various states of design.
the most recent version was in CVS, but is in the process of being moved. don't worry, as we have things for people to play with we'll let people know =)
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 =)
The more apps use tenor the more usefull it will be.
So, will it be kde-only or will other apps (Qt, gtk, any other) be able to feed data into it ?
Alex
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://!
That's kind of the wrong way of looking at it -- "Tenor" isn't something that users will use directly; it's a framework, not a tool or a specific interface component.
The way that it will show up to users is simply applications that work "smarter", search that works better, desktop browsing (in applications or the file browser) that knows about relationships.
So, it's not a tool and it's not storage abstraction; it's a mechanism to make applications able to work with context.
In this sense -- libkio is something that makes it possible to work with various sorts of input and output in KDE. Tenor is something that makes it possible to work with context.
There probably will be some specific new applications that emerge built completely around its capabilities, but that's the second step. :-)
"That's kind of the wrong way of looking at it -- "Tenor" isn't something that users will use directly; it's a framework, not a tool or a specific interface component."
I was under the impression that Tenor is somekind of "Spotlight on steroids" :). As in: a set of technology that can be embedded in to the system. Maybe I should RTFA again :).
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.
Charles.
do you have kde-multimedia installed? I guess you are just missing some part of KDE.
It's "audiocd:/" and "fish://" needs to go with a hostname or an IP, e.g. "fish://my.server.tld".
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?
To get a list of all the available protocols:
$ kcmshell ioslaveinfo
Its audiocd:/, and fish://hostname or fish:/
Which distro are you using?
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.
I've always thought something like ftp://ftp.server.com/file.tar#tar:/file/inside/it would make sense -- taking a cue from the webpage.html#anchor-to-jump-to syntax. Don't know whether it would conflict with anything else, though.
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.