KMountPoint::probablySlow and cifs mount points

[Aurélien Gâteau]

Le lundi 25 novembre 2013 18:23:53 Mark Gaiser a écrit :
> 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..

There is a vast difference between a progress bar running in the background 
and a message box asking a question to the user while the application is doing 
nothing.

> >> 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.

Capped connections for DSL lines do not exist anymore in France, but they do 
exist for cellphone contracts and everybody around me with such a contract is 
aware of them. I have no idea of what it is like in other countries though, 
but I believe that people are very quick learners when it comes to misfeatures 
leading to less money on their bank account :)

> >> 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.

Why would I suggest this if I can't be seriously thinking this is a good idea? 
For the pleasure of wasting your time?

> >> You open up a whole can of issues if you follow the "just copy and be
> >> done with it" route. An app should _never_ copy a file to display it
> >> or open it. It should either just open it and be slow as hell or _ask_
> >> the user really nicely if it can copy the file to his local system for
> >> improved performance.
> >> 
> >> All i'd like to do is very thoroughly talk the idea out of you that
> >> you can just automatically copy files if a connection is seemingly
> >> slow. If an app does that, it should ask first!
> > 
> > Users work with the "Don't make me think!" mantra. Asking before doing the
> > only doable thing is a bad user experience. What is needed though is a
> > progress indication to allow the user to cancel the operation if it takes
> > too long. A progress bar and a cancel button in the status bar for
> > example.
> Disagreed. The reasons should be obvious by now.

Reasons are not obvious at all to me, but I don't think we can agree there, so 
let's not pursue.

> >> >> What should be done is detecting is the target is mounted via a slow
> >> >> connection. So if it's mounted via the internet then "probablySlow"
> >> >> should return true. On the other hand, i don't know if such checks are
> >> >> in place and if they are not there, how to implement them.
> >> > 
> >> > Would be nice, but sounds difficult to do reliably, especially without
> >> > generating too much traffic.
> >> 
> >> I doubt that.
> >> If you do a ping or those kind of network tricks to figure out it's
> >> speed. Then yes, it will cause some traffic. And i don't think you
> >> should go for that.
> >> 
> >> What is possible - technically - is detecting if the connection is
> >> made through a wired internet connection, local network connection or
> >> even the same with wireless. Based on the "connection speed" that
> >> NetworkManager is just showing you, you can make a first guess if the
> >> connection is slow or fast. If you connect to an ip within the local
> >> IP ranges (10.x.x.x, 192.168.x.x etc..) then you can assume a fast
> >> local connection. Sure, that doesn't "need" to be true because you can
> >> also have VPN setups where ip's might seem local, but are in fact
> >> connected through the internet. There is no way to figure that out in
> >> a sane manner so they would have "false positives". That doesn't
> >> matter much. Those are the exceptions anyway. For other connections
> >> you can first do an nslookup (or trace route) to see if they are local
> >> or remote. Even then you can - yet again - argue that it's not going
> >> to work if you have a local dns server.. Again not important because
> >> those are the exceptions.
> > 
> > Sounds quite complicated: what about adding what Albert suggests until you
> > are done with writing this slow-network detection code?
> 
> As i said in my first reply. I have no say in this because i don't
> know this specific code nor own it. I'm not going to make this quite
> sophisticated detection or commit Albarts suggestion because it's not
> my place. Albert can make a patch which i guess is likely to be
> accepted. That doesn't mean i agree with it.

OK then let me rephrase my suggestion:

Sounds quite complicated: what about adding what Albert suggests until someone 
implements this slow-network detection code?


> > Aurélien
> 
> Lets sum up a little.
> You and i just have wildly different ideas about "what's right" here.
> You shoot down my points, i shoot down yours. That's ok and opens a
> nice discussion but is leading nowhere.

Agreed.

> I'm of the strong believe that
> a download is _only_ initiated by the users explicit permission. So if
> i update my system i - implicitly - allow the package manager to
> download updates. If i start to play a movie or open a document i
> allow the application to open the file and show it to me without
> downloading. Applications are usually very dumb in this area and
> should not try to outsmart the user by downloading a file. The
> intentions are good, the result is horrible.

What is so horrible about storing a local, hidden copy of a file while reading 
it?

> I vocally disagree to have some protocols as "probablySlow" because
> the entire reason for them to be probably slow is someone being crazy
> enough to do a mount via the internet. I would be very much in favor
> of killing the "probablySlow" function because we apparently have no
> real detection to even know if something is slow or not.

I use this method in Gwenview to decide whether it should use KIO or QFile to 
read an image file before decoding it, whether it should read embedded dates 
in JPEG headers and a few other things. I would not mind if the method were 
made smarter with the speed detection system you suggest, but I consider it 
useful already.

> All the
> protocols mentioned in this thread are fast if you use them on local
> area networks.

No they are not when used over wifi, which is nowadays the most common ways 
they are used.

Aurélien