Le lundi 25 novembre 2013 18:23:53 Mark Gaiser a =E9crit : > On Mon, Nov 25, 2013 at 5:41 PM, Aur=E9lien G=E2teau wrote: > > Le lundi 25 novembre 2013 13:54:38 Mark Gaiser a =E9crit : > >> On Mon, Nov 25, 2013 at 10:45 AM, Aur=E9lien G=E2teau =20 wrote: > >> > Le dimanche 24 novembre 2013 19:42:25 Mark Gaiser a =E9crit : > >> >> On Sun, Nov 24, 2013 at 5:05 PM, Albert Astals Cid =20 wrote: > >> >> > In Okular we just got bug > >> >> > https://bugs.kde.org/show_bug.cgi?id=3D327846 > >> >> > PDF Render time is unreasonably slow over cifs on high latenc= y (WAN) > >> >> > network connections > >> >> >=20 > >> >> > Basically the issue is that poppler is quite read-intensive o= ver > >> >> > files, > >> >> > reading them over and over, and since the file is "local but = really > >> >> > remote" it takes ages to render for big files. > >> >> >=20 > >> >> > The only solution i can think of is doing a local copy and th= en > >> >> > working > >> >> > on > >> >> > that. > >> >>=20 > >> >> That would work with small files (< 10 MB) but will get you int= o > >> >> trouble for bigger files. > >> >> You can't - or shouldn't - do that in an automated manner. If t= he user > >> >> manually copies the file and then opens it in a pdf reader: fin= e. Just > >> >> don't auto copy the file. So you can probably give the user a p= opup > >> >> suggesting them to copy the file to his local drive? > >> >=20 > >> > 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. > >>=20 > >> No. Here's why (again, but more detailed). > >> 1. People don't expect the file to be copied. Just to be opened. > >=20 > > Sure, the fact the file has been downloaded should not be exposed t= o the > > user, it should be downloaded in the background and removed afterwa= rd. >=20 > 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 backgr= ound=20 and a message box asking a question to the user while the application i= s doing=20 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. > >=20 > > I don't think users consider PDF files as streamable content that c= an be > > progressively read: it would make it impossible to do things like > > searching > > for text across the document: you need the whole document. People w= ith > > bandwidth caps are aware of them and will download the file themsel= ves > > before opening it. >=20 > 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 th= ey do=20 exist for cellphone contracts and everybody around me with such a contr= act is=20 aware of them. I have no idea of what it is like in other countries tho= ugh,=20 but I believe that people are very quick learners when it comes to misf= eatures=20 leading to less money on their bank account :) > >> 5. And what if i open an PDF (in this example) just to see the fir= st > >> page and then close it again. That is a needless copy. > >=20 > > I assume the copy is temporary, it is removed once Okular is closed= . > > Okular > > could start displaying the first pages while it is still downloadin= g in > > the > > background. I have no idea if this is possible with PDF files. >=20 > 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 goo= d idea?=20 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. > >>=20 > >> All i'd like to do is very thoroughly talk the idea out of you tha= t > >> you can just automatically copy files if a connection is seemingly= > >> slow. If an app does that, it should ask first! > >=20 > > Users work with the "Don't make me think!" mantra. Asking before do= ing the > > only doable thing is a bad user experience. What is needed though i= s 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 th= ere, so=20 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 "probablyS= low" > >> >> should return true. On the other hand, i don't know if such che= cks are > >> >> in place and if they are not there, how to implement them. > >> >=20 > >> > Would be nice, but sounds difficult to do reliably, especially w= ithout > >> > generating too much traffic. > >>=20 > >> 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. > >>=20 > >> 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 loc= al > >> 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 connection= s > >> you can first do an nslookup (or trace route) to see if they are l= ocal > >> or remote. Even then you can - yet again - argue that it's not goi= ng > >> to work if you have a local dns server.. Again not important becau= se > >> those are the exceptions. > >=20 > > Sounds quite complicated: what about adding what Albert suggests un= til you > > are done with writing this slow-network detection code? >=20 > 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=20 implements this slow-network detection code? > > Aur=E9lien >=20 > 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 i= f > 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=20 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 QF= ile to=20 read an image file before decoding it, whether it should read embedded = dates=20 in JPEG headers and a few other things. I would not mind if the method = were=20 made smarter with the speed detection system you suggest, but I conside= r it=20 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=20 they are used. Aur=E9lien