KMountPoint::probablySlow and cifs mount points

[Albert Astals Cid]

El Dilluns, 25 de novembre de 2013, a les 18:23:53, Mark Gaiser va escriure:
> On Mon, Nov 25, 2013 at 5:41 PM, Aurélien Gâteau <agateau at kde.org> wrote:
> > Le lundi 25 novembre 2013 13:54:38 Mark Gaiser a écrit :
> >> On Mon, Nov 25, 2013 at 10:45 AM, Aurélien Gâteau <agateau at kde.org> 
wrote:
> >> > Le dimanche 24 novembre 2013 19:42:25 Mark Gaiser a écrit :
> >> >> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid <aacid at kde.org> 
wrote:
> >> >> > In Okular we just got bug
> >> >> > https://bugs.kde.org/show_bug.cgi?id=327846
> >> >> > PDF Render time is unreasonably slow over cifs on high latency (WAN)
> >> >> > network connections
> >> >> > 
> >> >> > Basically the issue is that poppler is quite read-intensive over
> >> >> > files,
> >> >> > reading them over and over, and since the file is "local but really
> >> >> > remote" it takes ages to render for big files.
> >> >> > 
> >> >> > The only solution i can think of is doing a local copy and then
> >> >> > working
> >> >> > on
> >> >> > that.
> >> >> 
> >> >> That would work with small files (< 10 MB) but will get you into
> >> >> trouble for bigger files.
> >> >> You can't - or shouldn't - do that in an automated manner. If the user
> >> >> manually copies the file and then opens it in a pdf reader: fine. Just
> >> >> don't auto copy the file. So you can probably give the user a popup
> >> >> suggesting them to copy the file to his local drive?
> >> > 
> >> > I disagree with that: I believe the use should not have to worry about
> >> > this
> >> > and trust the application to be smart and do whatever is most
> >> > appropriate
> >> > to deliver the best result instead.
> >> 
> >> No. Here's why (again, but more detailed).
> >> 1. People don't expect the file to be copied. Just to be opened.
> > 
> > Sure, the fact the file has been downloaded should not be exposed to the
> > user, it should be downloaded in the background and removed afterward.
> 
> Here you say the user should not be bothered. Later on you say there
> should be some kind of process bar for the user to cancel..
> 
> >> 2. If you follow this route, you are already in the "probablySlow"
> >> path thus it copies over a likely slow connection. Have you though
> >> about the added bandwidth that takes? Not everyone is on unlimited
> >> insanely fast internet lines. Some people have bandwidth caps. For the
> >> record: i'm not one of those.
> > 
> > I don't think users consider PDF files as streamable content that can be
> > progressively read: it would make it impossible to do things like
> > searching
> > for text across the document: you need the whole document. People with
> > bandwidth caps are aware of them and will download the file themselves
> > before opening it.
> 
> Sorry, but this is a moot argument. People very often don't know if
> they have a bw limit or on what kind of connection they are. Not
> everyone is as technical as you and me.
> 
> >> 3. Copying it leaves the user puzzled as to where "the smart
> >> application" might have copied the data to.
> > 
> > Not if this is done transparently.
> > 
> >> 4. Copying also slowly eats your disc space. When i had this nasty
> >> surprise with a 10GB movie i wanted to play - not copy! - i was
> >> welcomed by a disc full error..
> > 
> > You can't compare the use case of a movie and a PDF. A movie is something
> > you expect to go through in one go. Arguably, you can also skip and go
> > back and forth, but it is much easier with movies than with PDF because
> > movie container formats were designed for that, and even with this
> > design, it does not work well with all network file systems.
> > 
> > As for disk space, it should be possible to check if there is enough disk
> > space before downloading, but again movies and PDF are quite different:
> > 10GB PDF may exists, but they are pretty much the exception.
> 
> Yeah.. And that is exactly the reason why i use KDE's KIO less and
> less to access network stuff. I - and i know the code! - don't even
> know exactly when app X or Y starts do download a file before playing
> it (mplayer) or just acts like it's bleeding and does nothing (dragon
> player). I simply mount partitions manually if i'm about to access the
> network for more then just browsing through folders.
> 
> >> 5. And what if i open an PDF (in this example) just to see the first
> >> page and then close it again. That is a needless copy.
> > 
> > I assume the copy is temporary, it is removed once Okular is closed.
> > Okular
> > could start displaying the first pages while it is still downloading in
> > the
> > background. I have no idea if this is possible with PDF files.
> 
> Oh fun.. So completely wasted bandwidth even. You can't seriously be
> thinking that this is a good idea.

Well, the user opened the file, he's expecting the bandwidth to be used, no? I 
mean why would he open the file otherwise? And FYI the current implementation 
uses much more bandwitdh as I already explained on your post, so not sure 
you're defending the right position here if bandwith is your concern.

Cheers,
  Albert