Nepomuk constraints

[Stefan Werden]

Thomas,
 
we have identified this problem as well. I think in Plasma Active ONE the
priority went really to "Make the new user experience happen". Indeed, there are
some negative impacts of deamons that eating up heavily resources. Be sure we
are working on this topic to speed up things. We made progress during the
development. The live image is about 3-5 times faster compared to the first
prototype sticks. And probaly we need to do this again!
The problem with these deaemons came up, because a normal low cost stick can
read with about 6-10 Mb/s and write 2,5-3,5 MB/s write. So if you start indexing
a 80MB oder 1.5 GB during firstboot of the stick this is more or less "Game
Over". If you take a faster stick the usb 2.0 normaly is not fast enough. USB3
will be better.
So if you have a normal disk with 70 MB/s+,  this just takes seconds what will
last a minute or more on a stick or an embedded device.
 
So we need to find solutions for "low performance hardware".
 
Hope this helps
 
Stefan 

Thomas Pfeiffer <colomar at autistici.org> hat am 11. Oktober 2011 um 21:42
geschrieben:

> Hi all,
> after using PA1 for a couple of days productively (for reading
> scientific papers while on the train), I noticed some effects of our
> heavy reliance on Nepomuk that I think we need to find a workaround for
> in PA2, namely startup and indexing.
>
> 1. The fact that it takes a very long time until file resources are
> available after boot is quite annoying, especially since there is no
> indication why the're not there.
> As a user not knowing how Nepomuk works, I would freak out every time I
> boot and my carefully configured activities all seem to be empty except
> for plasmoids. And I'd freak out even more if I tried to re-add the
> resources only to find that they are seemingly gone (!).
> Being someone who does know only very little about Nepomuk and Strigi, I
> ask myself: Why does it take so long to get the files ready on every
> boot? Shouldn't they only have to be indexed once and then be instantly
> ready?
> So we need to either
> 1. Get resources that have already been indexed ready much faster on
> subsequent boots (much preferred if possible in any way)
> 2. Show a placeholder at activities where resources are connected which
> are not ready yet, indicating they need to be loaded first
> The current situation will create a lot of confusion for novice users
> and quite some annoyance for advanced users (the device is practically
> unusable for the first few minutes if your activity is based mainly on
> documents or pictures)
>
> 2. Take a probably very common usecase: I use my device (of course not
> plugged to a socket since it's a mobile device) and I get a new file
> from the internet or a usb stick (the latter won't happen for novices in
> PA1 since there is no file browser, but in PA2 we'll have one). I want
> to connect it to an activity, but it doesn't show up.
> I remember that there was something about indexing, so I wait. And wait.
> And wait. And wonder why it's still not there.
> True story: After trying several things to get my damn files indexed
> (including deleting the nepomuk database but except plugging the device
> in, since I was on the train and then at work where I don't carry my
> adaptor) I finally resorted to deleting the .kde folder. Which, in turn,
> got me into _serious_ trouble ;)
> Long story short: It is a problem that new files won't get indexed
> without mains power because Strigi is suspended, again causing lots of
> confusion for users who don't have pretty deep knowledge of Nepomuk and
> Strigi.
> I have explained it in the FAQ now, so if we're lucky, users will find
> that information and won't suffer the same fate as I did (having to
> reinstall PA in the end because where I currently temporarily live the
> WiFi just won't work with the Wetab), but for PA2 we need to get new
> files indexed while on the go, because that's what users will be doing.
>
> Sorry if I sound overly negative here, but I'm sure that normal users
> will be bothered by things like these a lot more than I am.
>
> Looking forward to seeing these issues fixed (or worked around),
> Thomas
>
> _______________________________________________
> Active mailing list
> Active at kde.org
> https://mail.kde.org/mailman/listinfo/active
>
--
Dr. Stefan Werden
Managing Director
open-slx gmbh, HRB 25876,
Einsteinring 7, 90453 Nürnberg, Germany