[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