After a few months of quiet activity, the Appeal desktop project has rolled out a new project website that documents what everyone has been up to and discussing. Since the the last public announcement many things have occurred, including another Appeal meeting being held in Germany. The project is looking forward to sharing its experiences and gathering input from the general KDE developer community at aKademy 2005 later this month.
I totally agree with that FUSE should not be a means to implement anything.
I just wanted to point out that rather than requiring ReiserFS to store the metadata, it indeed would make much more sense, to make the KDE metadata engine available through a KIO-FUSE mount.
In the ReiserFS approach, Reiser4 becomes a dependency to Tenor.
In the other, which will be really done, KDE uses whatever it finds best suited to the job and creates a pseudo-filesystem to publish the metadata along with the files.
That way the circle will be closed. Solving too much inside the filesystem is bound for trouble.
Happy to work with anyone who wants to add version control to Reiser4, I do indeed think it would be easier to do it in reiser4 than in other filesystems......
"Happy to work with anyone who wants to add version control to Reiser4, I do indeed think it would be easier to do it in reiser4 than in other filesystems......"
Thank you very much for being open to cooperation with KDE in implementing file version control.
It remains to be seen whether KDE developers will opt for a completely filesystem-independent approach (which might have the drawback of not being transparent/portable to non-KDE apps), or opt for integration with ReiserFS 4, which would have a better chance of providing all apps on the system with access to file version data.
"It remains to be seen whether KDE developers will opt for a completely filesystem-independent approach , or opt for integration with ReiserFS 4."
I'd assume they'll let the backend decide that, i.e. offer some database backend for systems/partitions where no ReiserFS 4 is available and a ReiserFS 4 backend where it is.
well, i'm afraid the kde dev's might not be up to writing this and the other things tenor will need as plugins for reiser4. however, maybe linspire or suse will sponsor such an effort, as they (want to) include reiser4.
but first i think reiser4 must get into the kernel, and as long as reiser4 duplicates and extends the current VFS so much, this might take some time (or some feature-cutting from reiser4). these innovations should first be merged into the kernel, then the filesystem can follow, then tenor can use it.
but KDE4 is still at least a year (likely more) away... so we'll see.
btw i'd love to see this sponsorship, as i believe doing tenor the reiser4 way is The right thing to do (TM), and the most performant way. also, i think we'll be relying on this metadata more than we can ever imagine, and a database gets easilly corrupted. if i can't find my files because my database borked for the sixth time this year... i'd rather see it safe in an atomic filesystem!
Why is google linux not listed as one of the selectable
search engines. Url is: http://www.google.com/linux
what is linux
can"t you me explination about that
So should the kat be considered usable only with kde3 and that tenor is going to be the default desktop search engine for the kde4, and virtually obsoletes kat?
This might answer your question :-)
Thanks, it sure did... :-D
Kat might develop into tenor, as the upcoming 'tenor-team' will in part consist off members of the current kat-developers. they are working on the api and the capabilities, and as kat is already a nice application, it is more likely the tenor developers team up with them, instead of simply throwing all the work away.
Tenor is a framework and Kat is an application which might use the Tenor framework one day -- I see no conflicts there :-)
kat also has some framework aspects to it (the file system indexer, full text extraction..), and we're working together to take advantage of the work that has already been done. the kat framework parts are being improved upon and we'll be adding the contextual linkage aspects on to it.
kat framework will be enough evolved when, looking at the properties tab of a file that was moved many times into my hd, it will say "downloaded from the internet ($URL) 16 days ago" or "your friend sue gave sent this to you. track all the other files sent by her".. fanta-framework?
you've just described the contextual linkage side of it that Tenor is concentrating on. =)
Holy **** dude. I know that's what you mean when you talk about a contextual linkage system, but when it gets described to you it sounds wonderful. I really hope it can be achieved and you don't get bogged down.
The strange thing is, Microsoft and Apple are spending billions in research on this stuff and they're no closer to having a working solution - probably due in part to some historical reasons and the existing software they're working with. The open source world seems to be making great strides in this area, on much less of a budget (:-)) and could really take the lead in this area.
I am really excited about the development of the Appeal project. It is a great thing to see such a level of organized collaboration within the KDE community. As the process develops further I hope to see a page off of the Appeal website that gives a list of tasks or small jobs that need attention. Also, I would like to see on the KDE.org main page under the KDE Projects a link to the Appeal website. Thanks to all the developers working on this as a way to improve the KDE experience.