<div dir="ltr">HI Daf&nbsp;<div>Thank you for the explanation. also not making it a book :). &nbsp;<br><br><div class="gmail_quote">On Wed, Sep 10, 2008 at 6:44 PM, Dario Freddi <span dir="ltr">&lt;<a href="mailto:drf54321@gmail.com">drf54321@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hey people,<br>
I don&#39;t want to write the book, so I&#39;ll be quick as possible :D<br>
<br>
The best way to go, in our opinion, is Plasma. And this means that Raptor will<br>
be nothing but a popup applet, interacting with a dataengine. The dataengine<br>
will mostly hold a model that the applet will use for generating the view.</blockquote><div>&nbsp;</div><div>There are some unfinished popup applet code in svn.. we can have this popup in no time. and the libs will provide means of interacting with data engines. But the question is what if some one needs to write a non dataengine data source. some thing similar to weather engine with ions. &nbsp;so it would provide means to handle data engines and provide other simple engines too.&nbsp;</div>
<div>&nbsp;</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Let&#39;s talk about tom quickly. Me and riccardo discussed right today that every<br>
bit we need for raptor has already been implemented in KDE. So, we think the<br>
best solution for TOM would be using nepomuk based storage, by creating a new<br>
ontology. This would grant us an optimized database we can use to update our<br>
model.&nbsp;</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Riccardo has some other ideas about using some KRunners that I&#39;ll let him<br>
explain.<br>
<br>
So in the end I think we should keep the code simple, we don&#39;t need plugins or<br>
anything, that would just add a whole level of complexity without giving any<br>
real advantage. I&#39;d aim for code simplicity that would let us maintain it more<br>
easily.</blockquote><div><br class="webkit-block-placeholder"></div><div>&nbsp;I don&#39;t like to hard code&nbsp;</div><div>&nbsp;</div><div>a. ) syscoca for apps</div><div>b. ) neupomuk for that</div><div>c .) some thing for another.&nbsp;</div>
<div>&nbsp;</div><div>we agree on the fact that we need syscoca, nepomuk and some thing else...but not by the means explained here :)&nbsp;</div><div><br class="webkit-block-placeholder"></div><div>this idea is a good way to short&nbsp;circuit&nbsp;what&#39;s already planed . do you think dumping krunner code into raptor search is a&nbsp;wonderful&nbsp;solution ? this is how you build a monster .. the worst kind&nbsp;</div>
<div><br class="webkit-block-placeholder"></div><div>&nbsp;then it&#39;s much better to fock kickoff since it&#39;s&nbsp;already&nbsp;that.. raptor is a more wider and dynamic concept.. and it has to be complex no way around that.&nbsp;</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
I personally think this kind of approach (yes, it&#39;s just a very very short<br>
decscription) it&#39;s the best one, though I&#39;d like to hear some other voices<br>
<br>
Cheers<br>
Dario<br>
_______________________________________________<br>
Raptor mailing list<br>
<a href="mailto:Raptor@kde.org">Raptor@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/raptor" target="_blank">https://mail.kde.org/mailman/listinfo/raptor</a><br>
</blockquote><div>&nbsp;</div></div><br></div></div>