thoughts from FOSDEM, status

[Aaron J. Seigo]

On Saturday 19 March 2005 04:15, Scott Wheeler wrote:
>   Essentially Sevtap's question (and feel free to correct me) was along the
>   lines of, "Why not move the query logic into applications rather than a
>   central place?"  Essentially querying the applications as "agents" and
>   having them return things as such.
>
> I'm not sure that it's a practical approach, but it's certainly an
> interesting way of looking at the problem, so it's worth thinking about. 

ignoring the practical issues, i don't think this will work for several 
reasons:

1. information and application domains do not map similarly
2. puts too much onus on the application developer intead of giving them a 
tool
3. the next step is the network, and this will make things much more complex
4. we have multiple applications for the same information domains
5. i don't see what advantages it brings.

in more detail:

1. when looking at art, an artist may write books, make music, direct movies, 
do sculpture .. they may do all these things. however, we have separate 
applications that view books, view movies, listen to music and view pictures. 
so to tie this information together properly, one would require a central 
system to tie the individual results for "books", "music", etc together to 
the get overall picture of an artist. so breaking this up along applicaiton 
domains is a poor idea.

2. i fully expect that we will one day at least experiment with multiple 
threads / processes accessing the mesh and their results being used 
collectively. however, i don't think putting the onus on application 
developers is useful in the least. looks at kcontrol. the developers of 
kcontrol actually wanted to put in search and look how it ended up. most 
application developers couldn't care about it, save to use it as a tool. if 
we try and produce anything but a tool for application developers to consume, 
i fear it will fail utterly.

3. keeping an eyes to the future here, the next step is the network: tieing an 
entire office of these systems together. having each agent communicate with 
the network would likely be horrendous, which leads us to some sort of 
central switchboard. i think the network case will be tricky enough without 
having a machine-local network (the agents) that operates along a different 
set of dimensions to rationalize into the whole scheme.

4. for music, do the juk or the amarok people write the agent? which agent 
gets used? what about beep or...? i see a tower of babel arriving with this 
approach. unless the klink devels do all the work. ha ha.

5. so ... how is having agents better exactly? i understand it's different, 
but ... why?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/klink/attachments/20050319/26053618/attachment.pgp