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

List:       kde-devel
Subject:    Re: Nepomuk in 4.13 and beyond
From:       François_K. <daitheflu () free ! fr>
Date:       2013-12-18 11:09:02
Message-ID: 660614159.257821289.1387364942047.JavaMail.root () zimbra76-e14 ! priv ! proxad ! net
[Download RAW message or body]

Hi Vishesh, hi guys,

I'm sorry to short-circuit the thread. I deleted Vishesh's original email by \
mistake...

Well, that sounds really exciting ! Thanks again for your work.

Here are a few thoughts/questions I have since you've made the announcement. They \
might be a bit technical, I hope that's not a problem (should I start a new thread \
?).

* What are the plans to store tags ? On OSX, tags are stored in files xattrs which is \
                -IMHO- very nice :
  - Metadata live and die with the file ;
  - No "store" query when you move or copy a file ;
  - You don't rely on a "store" to tag files ;
  - You also don't end with a huge store full of unuseful things like it used to \
                happen with Nepomuk some time ago (no offense) ;
  - You can easily backup the metadata (at least files metadata) : you just have to \
                use a decent backup tool that handles xattrs ;
  - It's CLI-friendly ;
  - ...

* What are the plans to store indexes ? Again, with OSX (sorry, I work a lot with \
Macs -maybe too much-), the system builds an index per volume. This is quite nice \
because when you connect a volume that has already been indexed, the system gets the \
information and can immediatly search the volume index. Let's take an example : let's \
say you have some remote storage (NAS or whatever) at home with your medias. You \
mount this remote volume and let the indexers do their stuff. Then you mount the \
volume from another device and *tadaaa*, you're able to query the previously-built \
index. Wouldn't that be awesome ? If you disconnect the volume, the index for this \
volume isn't available anymore and you don't get results for it. This also means that \
if one index gets corrupted, you don't have to scan and index every volume again. I \
think this would also solve Ignacio's issue.

* You probably already know it, but SQLite DB might have some problems when stored on \
remote filesystems (see: http://www.sqlite.org/wal.html and especially "All processes \
using a database must be on the same host computer; WAL does not work over a network \
filesystem."). So if you plan to store each index on its volume (as previously \
suggested), SQLite might not be the (best) solution.

* Will there be several separated indexers (one for PDF files, one for video files, \
...) or just one that takes care of everything ? I was thinking about the ability to \
add indexers that could retrieve stuff from the Internet. For example, have an \
indexer that could retrieve movie information from TheMovieDB.org.

* I hope there will be a nice query API ? Dealing with Sparql was a nightmare for me \
!

* Will it come with a QML DataEngine ?

Thanks a lot,

-- 
François

> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


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