Bug 85594 - kst should allow datasource via fish (and perhaps others)
Summary: kst should allow datasource via fish (and perhaps others)
Status: RESOLVED FIXED
Alias: None
Product: kst
Classification: Applications
Component: datasources (show other bugs)
Version: 1.x
Platform: RedHat Enterprise Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: kst
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-07-21 01:29 UTC by Matthew Truch
Modified: 2005-02-08 04:05 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Truch 2004-07-21 01:29:26 UTC
Version:           0.99-devel (using KDE KDE 3.2.1)
Installed from:    RedHat RPMs
OS:                Linux

It could be useful if in addition to indirect data files, one could type something like fish://user@host/dir/with/data into the data source line to get data from affar.  Or even http:// or ftp:// etc.
Comment 1 George Staikos 2004-07-21 07:21:59 UTC
On Tuesday 20 July 2004 19:29, Matthew Truch wrote:
> It could be useful if in addition to indirect data files, one could type
> something like fish://user host/dir/with/data into the data source line to
> get data from affar.  Or even http:// or ftp:// etc.

  So far we decided not to do this by design due to performance issues 
(especially because we have to poll for real time updates).  I guess it 
should still be considered, but I'm not particularly convinced yet.

Comment 2 Matthew Truch 2004-07-21 17:16:27 UTC
I agree, for live data, it would 'suck' (technical term).  But for static data, it would definatly be useful; and polling shouldn't hurt much (other than network bandwidth and longer latencies in checkinig) in this case, as the data isn't changinig.  

Just a thought.
Comment 3 George Staikos 2004-07-21 19:19:50 UTC
On Wednesday 21 July 2004 11:16, Matthew Truch wrote:
> I agree, for live data, it would 'suck' (technical term).  But for static
> data, it would definatly be useful; and polling shouldn't hurt much (other
> than network bandwidth and longer latencies in checkinig) in this case, as
> the data isn't changinig.

   The bigger problem is this:

- Data sources do their own I/O so each would have to support KIO
- Most data sources use external libraries to read the data, so they have to 
copy the data file down to a temporary file and hopefully can clean it up 
properly
- Therefore we might as well just copy the file ourselves before we call out 
to the data source
- Completion and the wizard "Next" disable functionality basically breaks here 
in the KURLRequester because we can't try to open a new remote file each time 
the user types a character

So it's messy, but still conceivable.

Comment 4 George Staikos 2005-02-08 04:05:36 UTC
CVS commit by staikos: 

Add support for data sources via KIO.
FEATURE: 85594


  M +1 -1      datawizard.ui.h   1.114
  M +62 -10    kstdatasource.cpp   1.53
  M +1 -2      kstvectordialog_i.cpp   1.59