[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KMountPoint::probablySlow and cifs mount points
From:       Mark Gaiser <markg85 () gmail ! com>
Date:       2013-11-25 17:23:53
Message-ID: CAPd6JnE5mhPjg8HntKuh9hvyFNz+LsenAybD5tifCWfc9-fuTw () mail ! gmail ! com
[Download RAW message or body]

On Mon, Nov 25, 2013 at 5:41 PM, Aurélien Gâteau <agateau@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@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@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.
>
>> 6. You could even argue that you might violate intellectual property
>> stuff. Insane? No! For a past employer i had to read PDF files, but
>> was by no means allowed to copy them due to IP infringement if i did.
>> So i had to use an application that doesn't make caches, temp files or
>> copies internally and really just opens it, shows the data to me and
>> closes it. In other terms: no physical copy of that file was allowed
>> to be made without explicit permission of some management layer.
>
> That sounds like a corner case to me and I am not sure it matters as long as
> the local copy is removed at the end. If you dive into that hole you can also
> be worried about the application memory being swapped out to disk or the
> application crashing and dumping the document in a core file.

It is a corner case and was a high security environment.
>
>> 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.
>
>> >> 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.
>
> 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. 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.

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. All the
protocols mentioned in this thread are fast if you use them on local
area networks. That is how you are supposed to use them! It's awesome
that it works over WAN, but to always regard those protocols as
"probablySlow" is just stupid. If that's the case then you can add all
protocols to that list since you can even mound file:// over the
internet...
[prev in list] [next in list] [prev in thread] [next in thread]