[Kst] a bit of dcop philosophy

[George Staikos]

   I'm looking at the DCOP code here and trying to determine if I made the 
right choice.  Ideally we want to keep Kst very fast internally.  With this 
in mind, I kept the DCOP code completely separate from Kst.  It works on Kst 
essentially as though it is a black box and calls into it as necessary.  
There is another, more "pure" approach as well.  I could make each KstObject 
also be a DCOPObject.  The benefit is that we can explicitly expose the 
interface directly via DCOP.  We would have situations like this:

   dcop kst KstIface vector <somevectorname>

   This would return a DCOPRef to a vector, and then we could directly access 
it:

   dcop kst <vector ref> value 0

   As opposed to the current setup:

   dcop kst KstIface vector <somevectorname> 0

   It's much faster with the dcopref as it doesn't require lookups in the list 
each time, but it adds a bit more weight to each object.  It also gets messy 
if we want to have "nogui" support (d2asc) for KstObjects.  We would then 
have to link in dcop.

   Likewise, each plot, each equation, etc would have it's own DCOP reference 
available for the user.  The exposed methods are selectable (you use k_dcop: 
to specify).  

   A secondary disadvantage of making each KstObject a DCOPObject is that we 
either have to safeguard all the methods for bad input, or let the user crash 
the app with bad DCOP calls.

   A secondary advantage is that it might make integrating javascript simpler 
and/or make the JS interface more intuitive for the user.

   There is also the option of making each of the dialogs a DCOPObject.  I 
think this is a good idea regardless, but not particularily useful -yet-.

   What are your preferences?  Stay with what we have, or make each KstObject 
a DCOPObject?

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/