<br>I mostly agree on everything and I am happy to know that the current infrastructure will make it easy. Thanks for that ;)<br><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
</div><div class="Ih2E3d">> It surely is better implemented as a plasmoid independent of Krunner.<br>
<br>
</div>I'm not sure what you mean here? to me it seems like the perfect candidate for<br>
one or more AbstractRunner plugins.</blockquote><div><br>Let's differentiate two parts: the ones getting the job done and the one related to language. My thoughts explained below.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<div class="Ih2E3d"><br>
> So the project surely implies:<br>
> - A library (plasma engine?) to call the 3 types of resources above<br>
> (already created at least partially?)<br>
<br>
</div>that's the role of Plasma::AbstractRunner<br>
<div class="Ih2E3d"><br>
> - A definition of the language<br>
> - A configuration facility to let the language map to actions<br>
> and/or<br>
> - A configuration facility for the library (this allows other apps use its<br>
> "get map", etc. Services)<br>
<br>
</div>so this is where i think such a project would need to be careful in its<br>
design:<br>
<br>
the way runners work is that each is supposed to be specific to a given<br>
domain, e.g. web addresses, music collections, applications, etc. the<br>
benefits are:<br>
<br>
* easy to provide access to new domains by writing a AbstractRunner plugin.<br>
this can be done by a domain specialist, alleviating the need for someone who<br>
knows everything. you just need to know one domain =)<br>
<br>
* the code remains simple for each given domain (one runner -> one job)<br>
<br>
* allows the problem to be easily paralellized (a separate execution thread<br>
for each domain)<br>
<br>
* makes it easy to treat each domain separately for categorization, enabling<br>
or disabling that domain, etc<br>
<br>
so a project such as you are proposing should probably not try to<br>
implement "all possible things" in one runner, but define a language and then<br>
break the *static* parts of that language into their respective domains<br>
(writing runners for each) and then provide one "learning" runner that can be<br>
taught new/arbitrary commands.<br>
</blockquote><div><br><br><br>
Surely because of my lack of knowledge on the specifics of how runners works I thought of a possible problem:<br>
<br>
If you write:<br>
<a href="http://www.domain.com">http://www.domain.com</a> <br>
Surely you want to open a browser with that<br>
But it will be possible (if it is not working yet) that the files
downloaded from internet are annotated with the page from where they
were downloaded. Then you may mean search for that in your
metainformation.<br>
<br>
Or if you write 2+2 = you may want to calculate the value or search for "2+2=5" (a name of a song).<br>
<br>
So, what I thought was create domain specific runners as you said (the
current swith user, logout, etc. Functionality is a good example) and a
language to avoid ambiguities. ("search 2+2" or "calc 2+2" for
instance). Also, it can be a good idea to make the commands eventually produce information that could be inserted in other applications.<br>
<br>
But the "parse high level language and give the parsed information to
one domain specific runner" is pretty different and I'd say that even
incompatible with the "give the info to the runners and get the
results" that I think is how the current krunner works.<br>
That's why I was thinking in other plasmoid. If it is not needed, I _do_ prefer to integrate everything in the current runner. <br>
Of course, both will use the same plugins.<br></div></div><br><br clear="all"><br>-- <br>Jordi Polo Carres<br>NLP laboratory - NAIST<br><a href="http://www.bahasara.org">http://www.bahasara.org</a><br>