[Kat-development] Re: Anything about Tenor?

Manuel Amador rudd-o at amautacorp.com
Wed Aug 10 22:48:39 CEST 2005

El mar, 09-08-2005 a las 21:20 +0200, Roberto Cappuccio escribió:

> I was thinking, instead, to ask you to start building Tenor on top of Kat 
> technology. There is no reason to reinvent the wheel.

i tried to do that with search services as well, but it turns out tenor
is fundamentally different.  I still think tenor would especially
benefit from ZODB.

(btw we have a frontend for the search services, but it's not as
sophisticated as beagle)
> All in all, at the actual stage of development, Tenor is an empty box while 
> Kat is almost production ready.
> Kat is an architecture for desktop search, with its solid and expandable 
> database layer and API. Tenor could simply add contextual linkage to Kat's 
> architecture. 
> Anyway contextual linkage will represent IMHO a minimal part of the whole 
> architecture, maybe the most innovative and fascinating part, but still a 
> minimal part.
> In other words, I think that Tenor should be based on Kat and not vice-versa.
> > > (That said, I don't really like the interface of Kat, but that's another 
> matter.)
> The actual Catalog Browser is NOT the interface of Kat. 
> I know, we have not been particularly successful in explaining that to the 
> users... 
> Kat's interface will be integrated in Konqueror, in a way which is similar to 
> the actual "Search Files" feature.
> The Kat Catalog Browser will only be used for disconnected media, like CDs, 
> DVDs, USB dongles and the like, where the user will have the possibility to 
> browse the actual directory structure of a disk even if it is not inserted in 
> the drive.
> (That said, I would really like to see Tenor's interface, sooner or later, but 
> that's another matter.) :-D
> > Right, the current interface isn't that good, I never saw a search tool
> > where the actual search functionality is so well hidden as in kat ;-)
> As I said, it was not meant to be the primary search tool in Kat's 
> architecture.
> > But that will be improved soon, from the feature plan for 0.7.0: "Make a
> > brand new simple and usable search client" (they plan integration into
> > konqueror). 
> Exactly.
> > I think the client hasn't changed much since I tried kat the 
> > first time in its early days... 
> It is pretty the same since then. As I said before, it was not our main focus 
> to further develop it.
> > They put more effort into the backend, like 
> > the fulltext extractors, language detection, the indexer, and a kded daemon
> > that does the indexing in the background (monitoring changes using inotify,
> > which will be part of Linux kernel 2.6.13). There is also libkat in the
> > works so other apps can make use of kat.
> Yes, the backend got almost all of our attention. We wanted a modular 
> architecture which could be easily expanded, so we created the fulltext 
> kioslave and a series of fulltext plugins. 
> We are about to publish another 20 of them in the next release so that, from 
> this point of view, Kat will not have to fear competition.
> Using the same scientific principles that allow us to identify the language of 
> a document, we want to implement a highly innovative kind of search based on 
> linguistic fingerprints. 
> It will allow searches like: "find a document similar to this". No matter if 
> the words used in the documents differ, the linguistic fingerprint of 
> document belonging to the same domain, are similar. We want to exploit this 
> property of language.
> I would like you to notice that this feature is missing from ALL the 
> competitors.
> > > With that in mind, if Kat matures a bit it may make a nice mid-term
> > > solution so that we have something doing search-type stuff, but of course
> > > it doesn't cover some of the more interesting ideas from Tenor like
> > > contextual linkage and content management.
> Yesterday we moved to KDE SVN Playground and this gave me the possibility to 
> take a look to Tenor's directory.
> >From the empty stubs I have found therein, the things you want to develop, 
> apart from contextual linkage and content management (whatever you mean with 
> it) are already available in Kat.
> I don't think it would be a good thing to duplicate that features in Tenor or, 
> as you proposed, merge them in Tenor, since Kat is almost finished.
> We would therefore welcome you if you decide to help us to further develop our 
> infrastructure and then use it for building Tenor on top of it.
> So, I don't consider Kat a mid-term solution, but a fully fledged search 
> architecture that could be expanded and adopted by KDE as a standard.
> > I wonder if the KAT API could become a generic API for (context-less)
> > search.
> > Tenor could then implement the API as well, allowing easy migration 
> > of KAT-enabled apps to KAT/Tenor.
> Implement is not the right word. Tenor, like any other application needing 
> desktop search, could simply "use" the Kat API and eventually extend it with 
> contextual linkage and other sophisticated search technologies.
> > I really hope we can bring KAT and Tenor together and cooperate, instead of
> > having two competing solutions, maximizing confusion for developers and
> > users.
> My proposal is clear: I invite Scott Wheeler, Aaron Seigo and every other KDE 
> developer to join the Kat team and help building the Kat desktop search 
> infrastructure, to adopt it as the standard search architecture for KDE and 
> then to build the contextual linkage search on top of it.
> > Regards,
> >
> > Frank
> Bye
> Roberto
> _______________________________________________
> Klink mailing list
> Klink at kde.org
> https://mail.kde.org/mailman/listinfo/klink
Manuel Amador                   <rudd-o at amautacorp.com>
http://www.amautacorp.com/            +593 (4) 220-7010

More information about the Klink mailing list