[Kst] kst 2.x: dbus interface / datasource API

[nicolas.brisset at free.fr]

> Last couple weeks... redesigning the department's Ph.D. qualifying
> exam system, going through a draft of one of my student's Ph.D. thesis,
> editing another student's paper we hope to submit 'soon', planning a CSA
> meeting, and trying to get the BLASTpol telescope ready to fly...
Yeah, sounds like enough to keep you busy :-)
 
> We are funded, finally.  I am also trying to get the paperwork in
> order to hire.
Now, that is great news! Having full-time professional developers really boosts things. Now let's just hope you find the right profile quickly.
  
> data source API is a good 'high in the priority list' item.  
OK, good to know. I'll take part in the discussion.
 
> DCOP and javascript haven't been ported at all.  They are very similar
> jobs though. 
> -DCOP is dead.  If we do something like this, it will be DBUS.
Yes, that's pretty clear. 
But I think this functionality is very important to allow more advanced "cooperation" between tools than just starting kst from the command line.
We had a discussion today at the office towards how we'd like to integrate kst as plotting tool in a simulation environment, and clearly such an interface is very desirable (to be able to add a plot, remove one, etc... from kst while the simulation is running and a kst session already started).
Speaking of that, I was also wondering whether it would not be time to look into getdata. We will certainly investigate a bit in that area, though we were wondering how it performs if there are many variables to be written so often into so many files. File IO has the reputation of being slow. Is there some sort of buffering/memory caching being done? Is there a limit on the number of variables that can be recorded simultaneously? We routinely have simulations producing a few thousand vars at 50 Hz... Maybe in such a case netCDF or CDF are better choices?
 
> A big lurking issue is getting kst2 compatible with KDE releases. 
> There are a number of requirements for being a KDE extragear project, which we do
> not fulfill (like, for example, using KDE).
Well, I haven't explored this fully yet, but I think I have seen some Qt applications making use of KDE components when they are running under KDE (like the KDE file dialog). But I don't know whether this comes for free or has to be set up with some specific code. In any case, while I think it is nice to have a minimal set of requirements for kst, optional integration with KDE when available would certainly be a nice addition. I don't know what is in your plans in that respect, but in the longer term kst 2.x may still have a connection with KDE anyway. I don't feel like the issue you're mentioning is creating lots of pressure on us to move and be hosted somewhere else. And changing habits always has a cost...
Maybe we should just wait and see what happens with git over the next months?

Nicolas