Re: Moving Baloo forward
On Sunday 23 February 2014 12:21:24 GEO wrote: On Sunday 23 February 2014 12:14:30 Vishesh Handa wrote: On Thursday, February 20, 2014 08:58:48 AM GEO wrote: First of all: I am totally for xattr, thank you Vishesh for the great idea! Thanks, though the idea was Simeons. I just implemented some parts of it :) I was not able to find that out without any doubt in the wiki page: Are relations also stored as xattr? (Like: from etc.) This would be really awesome, as everything would be pretty reliable and portable. I understand that not everything makes sense to store in xattr and that you sometimes need unique identifiers for certain informations, but is some information about relations like for e.g. from: t...@mail.com stores in the file attributes? That would really make sense, as the same argument applies as for using xattr in the first place. Thank you very much!
Re: Moving Baloo forward
On Tuesday 21. January 2014 16.04.51 Vishesh Handa wrote: Well, anything is possible. Someone would just need to implement it. We had wanted to do something similar during the Nepomuk days as well, but it didn't quite materialize. Point me to roughly where in the stack to implement it, and I'll look into implement support for multimedia files. :-) -- Martin Sandsmark
Re: Moving Baloo forward
On Tuesday 21. January 2014 14.54.39 Thomas Lübking wrote: I *do* consider xattr the BY FAR more sane approach to the problem, but currently do frankly not see this on end user desktops :-( Luckily, we develop end-user desktops and the people who develop the other parts of this system are normal human beings that we can talk to. I'd suggest using xattrs, and get distro people to start enabling it by default. Other things to do would be to gray out the metadata editing stuff when viewing files on a filesystem without xattrs, with a short explanation, and get kio to warn you when you try to copy files with xattrs to a filesystem that doesn't support xattrs. -- Martin Sandsmark
Re: Moving Baloo forward
On Thursday, February 20, 2014 08:58:48 AM GEO wrote: First of all: I am totally for xattr, thank you Vishesh for the great idea! Thanks, though the idea was Simeons. I just implemented some parts of it :) -- Vishesh Handa
Re: Moving Baloo forward
On Sunday 23 February 2014 12:14:30 Vishesh Handa wrote: On Thursday, February 20, 2014 08:58:48 AM GEO wrote: First of all: I am totally for xattr, thank you Vishesh for the great idea! Thanks, though the idea was Simeons. I just implemented some parts of it :) I was not able to find that out without any doubt in the wiki page: Are relations also stored as xattr? (Like: from etc.) This would be really awesome, as everything would be pretty reliable and portable.
Re: Moving Baloo forward
On Friday, February 21, 2014 07:55:39 PM Thiago Macieira wrote: Em sex 21 fev 2014, às 21:00:07, Nicolás Alvarez escreveu: 2014-02-21 20:30 GMT-03:00 Sebastian Kügler se...@kde.org: On Thursday, February 20, 2014 08:58:48 GEO wrote: Maybe a strange idea, but it would resolve the privacy problem: Baloo could optionally encrypt all the attributes using a user defined password, meaning baloo stores encrypted strings as file attributes. I have no experience with file attributes, but I suppose the performance of search queries would suck, because of the decryption. Use an encrypted filesystem. :) It is not about using an encrypted file system, but about encrypted metadata when you copy to an external drive or share the file over dropbox etc. If the tags, ratings etc. are encrypted strings your metadata would be safe. That's a solution for a different problem. The problem in discussion is when you copy a file (perhaps to an unencrypted pendrive) unaware that you're also copying xattrs/metadata. Encrypting your main filesystem doesn't help with that. Is the metadata any more sensitive than the data itself? If you're copying a file to an unencrypted filesystem, then the data is no longer secure. You could a share a document not containing any personal information (a third party document stored on your hdd), but the comments or tags could contain information you do not want to share with others. Another question I could not find answered in the wiki: Is semantic information also stored in file attributes? (e.g. received from ), or does semantic information still rely on a database?
Re: Moving Baloo forward
On Samstag, 22. Februar 2014 10:37:04 CEST, GEO wrote: You could a share a document not containing any personal information (a third party document stored on your hdd), but the comments or tags could contain information you do not want to share with others. And you might just as well want to share/store them - there's just no proper auto-solution. The filemanger/kio will have to ask about what to do with the metadata and then it's just as easy to drop them. It should actually do so with *any* document type that contains metadata (docuement history telling, that says your boss is a complete tool...) but that would require knowledge of this metadata existence/format in the first place, so operating on the FS layer and using xattr or sidecars is far better then document specific metadata (an issue that could only be mitigated by eg. kio metadata plugins) Also I assume that for increased xattr support, dolphin would likely indicate them with an overlay and provide rw access through a rmb entry? That way you'd also see that you just copied a file including some metadata. Cheers, Thomas
Re: Moving Baloo forward
Em sáb 22 fev 2014, às 10:37:04, GEO escreveu: Is the metadata any more sensitive than the data itself? If you're copying a file to an unencrypted filesystem, then the data is no longer secure. You could a share a document not containing any personal information (a third party document stored on your hdd), but the comments or tags could contain information you do not want to share with others. It's just as likely that I may want to back up my data with the metadata. Also, considering many file formats support embedded revisions and comments, before sharing stuff you should always run a cleaner. Many a big company were caught putting out documents in Microsoft Word formats where one could read older revisions and comments. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Moving Baloo forward
First of all: I am totally for xattr, thank you Vishesh for the great idea! Maybe a strange idea, but it would resolve the privacy problem: Baloo could optionally encrypt all the attributes using a user defined password, meaning baloo stores encrypted strings as file attributes. I have no experience with file attributes, but I suppose the performance of search queries would suck, because of the decryption. There will always be users who do not have any idea of security, so I think it does not make sense to choose a technically inferior implementation by default, just because of people not understanding much of it anyway. Looking forward to the release! -- View this message in context: http://kde.6490.n7.nabble.com/Moving-Baloo-forward-tp1556434p1560700.html Sent from the kde-core-devel mailing list archive at Nabble.com.
Re: Moving Baloo forward
On Thursday, February 20, 2014 08:58:48 GEO wrote: Maybe a strange idea, but it would resolve the privacy problem: Baloo could optionally encrypt all the attributes using a user defined password, meaning baloo stores encrypted strings as file attributes. I have no experience with file attributes, but I suppose the performance of search queries would suck, because of the decryption. Use an encrypted filesystem. :) -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Moving Baloo forward
2014-02-21 20:30 GMT-03:00 Sebastian Kügler se...@kde.org: On Thursday, February 20, 2014 08:58:48 GEO wrote: Maybe a strange idea, but it would resolve the privacy problem: Baloo could optionally encrypt all the attributes using a user defined password, meaning baloo stores encrypted strings as file attributes. I have no experience with file attributes, but I suppose the performance of search queries would suck, because of the decryption. Use an encrypted filesystem. :) That's a solution for a different problem. The problem in discussion is when you copy a file (perhaps to an unencrypted pendrive) unaware that you're also copying xattrs/metadata. Encrypting your main filesystem doesn't help with that. -- Nicolás
Re: Moving Baloo forward
Em sex 21 fev 2014, às 21:00:07, Nicolás Alvarez escreveu: 2014-02-21 20:30 GMT-03:00 Sebastian Kügler se...@kde.org: On Thursday, February 20, 2014 08:58:48 GEO wrote: Maybe a strange idea, but it would resolve the privacy problem: Baloo could optionally encrypt all the attributes using a user defined password, meaning baloo stores encrypted strings as file attributes. I have no experience with file attributes, but I suppose the performance of search queries would suck, because of the decryption. Use an encrypted filesystem. :) That's a solution for a different problem. The problem in discussion is when you copy a file (perhaps to an unencrypted pendrive) unaware that you're also copying xattrs/metadata. Encrypting your main filesystem doesn't help with that. Is the metadata any more sensitive than the data itself? If you're copying a file to an unencrypted filesystem, then the data is no longer secure. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Moving Baloo forward
On Wed, Jan 29, 2014 at 8:49 AM, Todd toddr...@gmail.com wrote: What about something like what Dolphin has now, where when you drop a file on a removable filesystem or remote drive it pops up the current copy/move/link option, but also has a checkbox (disabled by default buy configurable) to copy metadata or copy tags or something along those lines? Well it's a menu, once you select an action, the menu goes away, checkbox or not. I imagine there are some ways (hacks?) howto make menu a small sort of modal dialog, but then imho it would be better to have Copy and Copy with metadata. Oh and the visual clutter it would bring to that simple menu...dunno, sounds too complicated imo. What we could do with regards to educating users, is what Google does these days - when there's a new feature in any Google product, it shows a little bubble shortly explaining what is it about with two buttons - Okay, got it and Show me more. I can imagine something similar first time you copy a file/open dolphin/some other action. Shown once and never more. Too bad if the users misses it though :) Cheers -- Martin Klapetek | KDE Developer
Re: Moving Baloo forward
On Wednesday, 2014-01-29, 00:06:11, Ingo Klöcker wrote: I don't think it makes sense to work around a social problem (uneducated users) by using an inferior and much more complex technical solution (some database instead of xattrs). IMHO the advantages of using xattrs (e.g. we get easy synchronization and backup of metadata for free) outweigh the possibility that some people might inadvertently publish private metadata. People need to be educated that they have to use their brains when they share stuff. And we need to make sharing stuff (with built-in privacy protection) as easy as possible. As you pointed out below, most sharing technologies automatically discard xattrs anyway. The only sharing option that would not that I can come up with is having a shared directory on a filesystem with xattrs support. The question for that is whether it is not the administrator responsibility to set it up without xattrs support if privacy between sharing parties is a concern. Moreover, the risk for privacy is significantly lower than with metadata that is stored in the file itself (as in your MS Word document example). In contrast to metadata stored in MS Word documents, metadata stored in xattrs will not be leaked if you share the file via mail or by uploading it to Facebook or by copying it on a (FAT32-formatted) USB-stick. Apparently, Dropbox supports xattrs, but IMHO it's Dropbox's responsibility to provide a setting to disable synchronization of file metadata. My guess would be that DropBox or any other synchronisation service only does that for sync clients, not when enabling outside access to the same data. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
Am Dienstag, 28. Januar 2014, 22:06:45 schrieb Rolf Eike Beer: Am Dienstag, 28. Januar 2014, 20:10:13 schrieb Ivan Čukić: To move a file to another machine and have the metadata be copied and re- indexed on that new machine as well. The copy process just needs to take care of transfering the xattr. This can even work when using a USB stick or so as interim medium. I'm all for xattrs, but this thread really raises a nice question of which annotations/tags/whatever should be public and which should not. IMHO the default should be privacy first. Probably everyone of us has laughed about someone who accidentially published either metadata or deleted text (remember MS Word document history or something)? I'm absolutely fine if you want this that you do this. But most people will not be aware of it, even less of the implications. So it should be deactivated by default and only activated explicitely. Hmmm, right, didn´t actually think of the privacy implications. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
Am Dienstag, 28. Januar 2014, 08:03:54 schrieb Rolf Eike Beer: Am Freitag, 24. Januar 2014, 15:59:12 schrieb Vadim Zhukov: 2014/1/24 Sebastian Kügler se...@kde.org: On Friday, January 24, 2014 01:24:54 Vadim Zhukov wrote: in the best case you'll have two totally different codepaths that you'll have to manage. This should be worst case, I think. In the best case, there's xattr support, meaning another code path isn't needed. It's doubtful at least whether xattr support is a good thing, because it's too easily gets misused: for example, there were viruses on Windows which effectively hidden themselves in NTFS streams. And there are personal data leaking issues I've pointed out earlier. But the question xarttrs: to be or not to be everywhere is totally offtopic, because it's what OS developers should decide. I am against storing metadata in xattrs, but more for personal opinion than for anything I can express in technical terms. What could be done and which uses xattrs for what I seem them for is to just store a unique identifier in the xattrs (e.g. a GUID) which makes it easier to map the file to its metadata in the database, maybe together with some sort of checksum to detect modifications. That way no accidential information leak will happen if that thing is copied elsewhere. Storing metadata in xattrs makes a really nice feature possible: To move a file to another machine and have the metadata be copied and re- indexed on that new machine as well. The copy process just needs to take care of transfering the xattr. This can even work when using a USB stick or so as interim medium. A database ID would not be sufficient for that. Actually I very much like that as a feature. With current Nepomuk I expect to loose any key words and other metadata when I transfer some files to another machine. Of course, if its just my user data I can also transfer my complete home directory when migrating to a new box. But any exchange of data between users will use any and all metadata that is not directly stored in the file unless they are transferred somehow like via xattr. -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
Am Dienstag, 28. Januar 2014, 20:10:13 schrieb Ivan Čukić: To move a file to another machine and have the metadata be copied and re- indexed on that new machine as well. The copy process just needs to take care of transfering the xattr. This can even work when using a USB stick or so as interim medium. I'm all for xattrs, but this thread really raises a nice question of which annotations/tags/whatever should be public and which should not. IMHO the default should be privacy first. Probably everyone of us has laughed about someone who accidentially published either metadata or deleted text (remember MS Word document history or something)? I'm absolutely fine if you want this that you do this. But most people will not be aware of it, even less of the implications. So it should be deactivated by default and only activated explicitely. Eike signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
On Tuesday 28 January 2014 22:06:45 Rolf Eike Beer wrote: Am Dienstag, 28. Januar 2014, 20:10:13 schrieb Ivan Čukić: To move a file to another machine and have the metadata be copied and re- indexed on that new machine as well. The copy process just needs to take care of transfering the xattr. This can even work when using a USB stick or so as interim medium. I'm all for xattrs, but this thread really raises a nice question of which annotations/tags/whatever should be public and which should not. IMHO the default should be privacy first. Probably everyone of us has laughed about someone who accidentially published either metadata or deleted text (remember MS Word document history or something)? I'm absolutely fine if you want this that you do this. But most people will not be aware of it, even less of the implications. So it should be deactivated by default and only activated explicitely. I don't think it makes sense to work around a social problem (uneducated users) by using an inferior and much more complex technical solution (some database instead of xattrs). IMHO the advantages of using xattrs (e.g. we get easy synchronization and backup of metadata for free) outweigh the possibility that some people might inadvertently publish private metadata. People need to be educated that they have to use their brains when they share stuff. And we need to make sharing stuff (with built-in privacy protection) as easy as possible. Moreover, the risk for privacy is significantly lower than with metadata that is stored in the file itself (as in your MS Word document example). In contrast to metadata stored in MS Word documents, metadata stored in xattrs will not be leaked if you share the file via mail or by uploading it to Facebook or by copying it on a (FAT32-formatted) USB-stick. Apparently, Dropbox supports xattrs, but IMHO it's Dropbox's responsibility to provide a setting to disable synchronization of file metadata. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
On Tue, Jan 28, 2014 at 10:06 PM, Rolf Eike Beer k...@opensource.sf-tec.dewrote: Am Dienstag, 28. Januar 2014, 20:10:13 schrieb Ivan Čukić: To move a file to another machine and have the metadata be copied and re- indexed on that new machine as well. The copy process just needs to take care of transfering the xattr. This can even work when using a USB stick or so as interim medium. I'm all for xattrs, but this thread really raises a nice question of which annotations/tags/whatever should be public and which should not. IMHO the default should be privacy first. Probably everyone of us has laughed about someone who accidentially published either metadata or deleted text (remember MS Word document history or something)? I'm absolutely fine if you want this that you do this. But most people will not be aware of it, even less of the implications. So it should be deactivated by default and only activated explicitely. Eike What about something like what Dolphin has now, where when you drop a file on a removable filesystem or remote drive it pops up the current copy/move/link option, but also has a checkbox (disabled by default buy configurable) to copy metadata or copy tags or something along those lines?
Re: Moving Baloo forward
On 01/26/14 00:38, Matthew Dawson wrote: On January 25, 2014 10:02:09 PM Thomas Lübking wrote: On Samstag, 25. Januar 2014 21:03:44 CEST, Matthew Dawson wrote: At least for ext4, xattrs are the default mode Indeed - removed user_xattr and they're still there. Do you happen to know when this happened? (google got me a patch suggest from mid 2011 but i found no hey heads up: xattr now default on ext4) Sorry for the dated information and thanks for the info), Thomas I have no idea when it happened, as I only found out when I tried to enable xattr on one of my file systems. I was surprised by it as well. CONFIG_EXT4_FS_XATTR is now always enabled as of 3.7. See commit 939da1084458246d2e29dd921c2012c177000e96 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=939da1084458246d2e29dd921c2012c177000e96 Linux 3.7 has been released https://lkml.org/lkml/2012/12/10/688 on 10 Dec 2012. I don't know if simply upgrade the kernel add xattr support of mkfs is needed
Re: Moving Baloo forward
2014/1/24 Sebastian Kügler se...@kde.org: On Friday, January 24, 2014 01:24:54 Vadim Zhukov wrote: in the best case you'll have two totally different codepaths that you'll have to manage. This should be worst case, I think. In the best case, there's xattr support, meaning another code path isn't needed. It's doubtful at least whether xattr support is a good thing, because it's too easily gets misused: for example, there were viruses on Windows which effectively hidden themselves in NTFS streams. And there are personal data leaking issues I've pointed out earlier. But the question xarttrs: to be or not to be everywhere is totally offtopic, because it's what OS developers should decide. The worst case is Nepomuk becoming a crashy resource hog again, which will turn in cutting it off or disabling by default in most OSes. -- WBR, Vadim Zhukov
Re: Moving Baloo forward
On Freitag, 24. Januar 2014 12:59:12 CEST, Vadim Zhukov wrote: It's doubtful at least whether xattr support is a good thing, because it's too easily gets misused: for example, there were viruses on Windows which effectively hidden themselves in NTFS streams. IOW: It's doubtful at least whether using Windows is a good thing, because it's full of viruses. ...That's seriously no argument - viruses can hide themselve everywhere. And there are personal data leaking issues I've pointed out earlier. You're right in that at least kio/dolphin should be xattr aware and present you attributes and ask what to do on effectively copying them. However, *many* files leak private data, carried in their own metadata formats. The problem is simply extended to ASCII, but otoh, that metadata is at least standardized. The worst case is Nepomuk becoming a crashy resource hog again Playing that game on, the worst case would be if your computer overheats, explodes, kills you and your family and burns down your house which will lead to burning down the entire city what will feed global warming to exterminate mankind. Therefore humans cannot develop a way to protect the galaxy from a mega black hole that ultimately sucks away the entire universe. So better stick with the topic of best/worst case scenario of utilizing xattrs where some basically dead code is indeed the worst case - certainly not the best. Cheers, Thomas
Re: Moving Baloo forward
Am Freitag, 24. Januar 2014, 15:59:12 schrieb Vadim Zhukov: 2014/1/24 Sebastian Kügler se...@kde.org: On Friday, January 24, 2014 01:24:54 Vadim Zhukov wrote: in the best case you'll have two totally different codepaths that you'll have to manage. This should be worst case, I think. In the best case, there's xattr support, meaning another code path isn't needed. It's doubtful at least whether xattr support is a good thing, because it's too easily gets misused: for example, there were viruses on Windows which effectively hidden themselves in NTFS streams. And there are personal data leaking issues I've pointed out earlier. But the question xarttrs: to be or not to be everywhere is totally offtopic, because it's what OS developers should decide. I am against storing metadata in xattrs, but more for personal opinion than for anything I can express in technical terms. What could be done and which uses xattrs for what I seem them for is to just store a unique identifier in the xattrs (e.g. a GUID) which makes it easier to map the file to its metadata in the database, maybe together with some sort of checksum to detect modifications. That way no accidential information leak will happen if that thing is copied elsewhere. Eike signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
On January 21, 2014 02:54:39 PM Thomas Lübking wrote: On Dienstag, 21. Januar 2014 13:37:29 CEST, viv...@gmail.com wrote: And windows? HPFS/NTFS has xattr support (through alternative data streams) and WINNT supports handling xattr on FAT as well. The problem about xattr is rather that 99% of all ext3/4 users will atm get setfattr: filename: Operation not supported At least for ext4, xattrs are the default mode for any filesystem, and require a flag to explicitly disable them. Unless there are many distros out there adding that flag to fstab, it shouldn't be a problem. -- Matthew smime.p7s Description: S/MIME cryptographic signature
Re: Moving Baloo forward
On Samstag, 25. Januar 2014 21:03:44 CEST, Matthew Dawson wrote: At least for ext4, xattrs are the default mode Indeed - removed user_xattr and they're still there. Do you happen to know when this happened? (google got me a patch suggest from mid 2011 but i found no hey heads up: xattr now default on ext4) Sorry for the dated information and thanks for the info), Thomas
Re: Moving Baloo forward
On January 25, 2014 10:02:09 PM Thomas Lübking wrote: On Samstag, 25. Januar 2014 21:03:44 CEST, Matthew Dawson wrote: At least for ext4, xattrs are the default mode Indeed - removed user_xattr and they're still there. Do you happen to know when this happened? (google got me a patch suggest from mid 2011 but i found no hey heads up: xattr now default on ext4) Sorry for the dated information and thanks for the info), Thomas I have no idea when it happened, as I only found out when I tried to enable xattr on one of my file systems. I was surprised by it as well. -- Matthew smime.p7s Description: S/MIME cryptographic signature
Re: Moving Baloo forward
2014/1/21 Thomas Lübking thomas.luebk...@gmail.com: On Dienstag, 21. Januar 2014 13:37:29 CEST, viv...@gmail.com wrote: And windows? HPFS/NTFS has xattr support (through alternative data streams) and WINNT supports handling xattr on FAT as well. The problem about xattr is rather that 99% of all ext3/4 users will atm get setfattr: filename: Operation not supported ie. xattr nowhere being activated. This would have to change dramatically in order to make a xattr implementation useful. Next thing is global xattr awareness, ie. one has to consider that even if kio/dolphin would have great xattr support and cp aliasing -a by default etc., the user might move/copy the data using nautilus or some other lousy filemanager :-P I *do* consider xattr the BY FAR more sane approach to the problem, but currently do frankly not see this on end user desktops :-( Linux/Desktop has to become a xattr OS before relying on it - thus imo xattr support could only be explicitly optional to get there. Otherwise ubuntusers™ will complain loosing their metadata all the time. Unfortunately this isn't MacOS where SJ. just said: do or you're fired, you censored! Keeping metadata in id3v2/xmp/iptc unfortunately only covers few filetypes (w/o invoking sidecars, ie. what __MACOSX does when entering the outer world) - directories could be stored in .directory xattrs are not available in neither NetBSD, DragonFlyBSD nor in OpenBSD (which will ship 4.11.5 in the next release). And what's for read-only mounted file systems? And what will happen if the file with xattr is saved on a flash drive, and then transferred to another computer? In case with separate DB it'll be just lost, maybe not immediately. In case of xattrs, other user will receive this info, which is not good itself at least. And this may cause Baloo misbehaving, no? I'm all for improving current situation with Nepomuk, and appreciate any steps in this direction a lot. But, please, do not use xattrs here: in the best case you'll have two totally different codepaths that you'll have to manage. -- WBR, Vadim Zhukov
Re: Moving Baloo forward
On Friday, January 24, 2014 01:24:54 Vadim Zhukov wrote: in the best case you'll have two totally different codepaths that you'll have to manage. This should be worst case, I think. In the best case, there's xattr support, meaning another code path isn't needed. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
Re: Moving Baloo forward
Well, the 'worst case' is actually the real case. But, the thing is that it will be actively tested and developed simply because we will have both filesystems with xattr (home etc.), and without (vfat usb-s, encfs stuff and similar). So, both are used at the same time, and regressions will be noticed and fixed immediately. This situation is not the same as doubling the code-paths due to hal/u*stuff/whatever else, x11/wayland etc. where you tend to use only one technology, and not the other. Ch! On 24 January 2014 12:39, Sebastian Kügler se...@kde.org wrote: On Friday, January 24, 2014 01:24:54 Vadim Zhukov wrote: in the best case you'll have two totally different codepaths that you'll have to manage. This should be worst case, I think. In the best case, there's xattr support, meaning another code path isn't needed. Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun
Re: Moving Baloo forward
Am Dienstag, 21. Januar 2014, 02:10:21 schrieb Vishesh Handa: On Saturday 18 January 2014 12:53:38 Jonathan Marten wrote: Vishesh Handa m...@vhanda.in writes: http://community.kde.org/Baloo Thanks for producing that useful page, and of course for all your past and current work on Nepomuk and Baloo. There is one statement there that makes me a little concerned: This metadata is now stored with the extended attributes of the file instead of storing it in a separate database. Am I right in assuming that this means xattr? If so, would there be implications for cases where those extended attributes may not get preserved or are not supported: - simple copy/move of a file using cp/mv (with the default options) - copy/move of a file using KIO - network file systems (NFS or SMB) - backup/restore - FAT filesystems - platforms other then Linux Hoping that none of those will make normal use impossible, but if there would be problems or workarounds needed with any of these then they ought to be addressed early. […] The idea is that in systems which do not support xattr a secondary database will be used to store the information. So, it will be very similar to the situation we had with Nepomuk. I still have to implement this. As a user feedback: I like the idea of using xattrs a lot. And also your effort with Baloo. I was a bit surprised by it as of now finally the Nepomuk stuff basically works on my system. I think that secondary database as backup if xattrs are not available is important. E.g. I wonder whether xattrs are available with - NFS mounted homes (especially when those are backed by non-linux NFS implementations like from NetApp) or through - ecryptfs and other stacked filesystem approaches. Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Re: Moving Baloo forward
2014/1/21 Vishesh Handa m...@vhanda.in On Tuesday 21 January 2014 02:24:01 Francesco R. wrote: just always use an additional database, xattrs are not the way to go. Managing xattrs require a conscious user, many programs by default don't even copy xattrs. Plus, with extended attributes the metadata is never lost. With the additional database, if the file is moved to a place which is not tracked, then the data will be lost. I'm just curious, the additional database uses the filename or a hash of the file content as the key for the metadata? -- Vishesh Handa [1] http://www.freedesktop.org/wiki/CommonExtendedAttributes/
Re: Moving Baloo forward
On Tuesday 21 January 2014 12:37:14 Jaime wrote: 2014/1/21 Vishesh Handa m...@vhanda.in On Tuesday 21 January 2014 02:24:01 Francesco R. wrote: just always use an additional database, xattrs are not the way to go. Managing xattrs require a conscious user, many programs by default don't even copy xattrs. Plus, with extended attributes the metadata is never lost. With the additional database, if the file is moved to a place which is not tracked, then the data will be lost. I'm just curious, the additional database uses the filename or a hash of the file content as the key for the metadata? Currently we have one sqlite db which is responsible for mapping file urls - integer identifiers. We also install inotify watches on EVERY folder in your home directory. When a file moves the db is updated. This unique integer identifier (henceforth called file id), is used to map the indexed data to the file. When this alternate database will be used to store tags, ratings, etc instead of xattr, at that time this file id will be used to uniquely identify the file. -- Vishesh Handa
Re: Moving Baloo forward
On Tuesday 21 January 2014 13:06:40 viv...@gmail.com wrote: On 01/21/14 11:50, Vishesh Handa wrote: On Tuesday 21 January 2014 02:24:01 Francesco R. wrote: just always use an additional database, xattrs are not the way to go. Managing xattrs require a conscious user, many programs by default don't even copy xattrs. I disagree. It'll be easier to backup / restore xattr than it would be with that database. Additionally, a LOT of tools do respect extended attributes (cp with the -a flag), in contrast Nepomuk has never copied any metadata. I doubt I can implement it with the extra database as well. Plus, with extended attributes the metadata is never lost. With the additional database, if the file is moved to a place which is not tracked, then the data will be lost. So we agree to disagree ;) especially on the never lost part, when moved with kio they will be lost, when using unix command line programs, and without special arguments they will be lost. When copied not moved. Most important of all they are normally hidden, more hidden than a .dot file, an additional database, even a .dot file is much more easy to remember. $ echo Hello a $ attr -s simple.attibute -V test for xattr ./a Attribute simple.attibute set to a 14 byte value for ./a: test for xattr $ kioclient cp a b $ attr -l b empty kio can be modified :) $ cp a b $ attr -l b empty $ cp -a a b $ attr -l b Attribute simple.attibute has a 14 byte value for b $ rm b $ rsync a b $ attr -l b empty $ rsync -X a b $ attr -l b Attribute simple.attibute has a 14 byte value for b Maybe we could push distros to enable the -a flag by default? Mac does it by default. -- Vishesh Handa
Re: Moving Baloo forward
On Tue, Jan 21, 2014 at 11:50 AM, Vishesh Handa m...@vhanda.in wrote: On Tuesday 21 January 2014 02:24:01 Francesco R. wrote: just always use an additional database, xattrs are not the way to go. Managing xattrs require a conscious user, many programs by default don't even copy xattrs. I disagree. It'll be easier to backup / restore xattr than it would be with that database. Additionally, a LOT of tools do respect extended attributes (cp with the -a flag), in contrast Nepomuk has never copied any metadata. I doubt I can implement it with the extra database as well. Plus, with extended attributes the metadata is never lost. With the additional database, if the file is moved to a place which is not tracked, then the data will be lost. Would it be possible to store the metadata inside files that support it (like images or music files) and use xattrs only for files that don't have their own internal metadata format?
Re: Moving Baloo forward
Il 21/01/2014 02:10, Vishesh Handa ha scritto: On Saturday 18 January 2014 12:53:38 Jonathan Marten wrote: Vishesh Handa m...@vhanda.in writes: http://community.kde.org/Baloo Thanks for producing that useful page, and of course for all your past and current work on Nepomuk and Baloo. There is one statement there that makes me a little concerned: This metadata is now stored with the extended attributes of the file instead of storing it in a separate database. Am I right in assuming that this means xattr? If so, would there be implications for cases where those extended attributes may not get preserved or are not supported: - simple copy/move of a file using cp/mv (with the default options) - copy/move of a file using KIO - network file systems (NFS or SMB) - backup/restore - FAT filesystems - platforms other then Linux Hoping that none of those will make normal use impossible, but if there would be problems or workarounds needed with any of these then they ought to be addressed early. Hey The idea is that in systems which do not support xattr a secondary database will be used to store the information. So, it will be very similar to the situation we had with Nepomuk. just always use an additional database, xattrs are not the way to go. Managing xattrs require a conscious user, many programs by default don't even copy xattrs. I still have to implement this. maybe start without additional metadata, but xattrs must not reach user systems Regards, Jonathan Regards, Francesco Riosa
Re: Moving Baloo forward
On 01/21/14 11:50, Vishesh Handa wrote: On Tuesday 21 January 2014 02:24:01 Francesco R. wrote: just always use an additional database, xattrs are not the way to go. Managing xattrs require a conscious user, many programs by default don't even copy xattrs. I disagree. It'll be easier to backup / restore xattr than it would be with that database. Additionally, a LOT of tools do respect extended attributes (cp with the -a flag), in contrast Nepomuk has never copied any metadata. I doubt I can implement it with the extra database as well. Plus, with extended attributes the metadata is never lost. With the additional database, if the file is moved to a place which is not tracked, then the data will be lost. So we agree to disagree ;) especially on the never lost part, when moved with kio they will be lost, when using unix command line programs, and without special arguments they will be lost. Most important of all they are normally hidden, more hidden than a .dot file, an additional database, even a .dot file is much more easy to remember. $ echo Hello a $ attr -s simple.attibute -V test for xattr ./a Attribute simple.attibute set to a 14 byte value for ./a: test for xattr $ kioclient cp a b $ attr -l b empty $ cp a b $ attr -l b empty $ cp -a a b $ attr -l b Attribute simple.attibute has a 14 byte value for b $ rm b $ rsync a b $ attr -l b empty $ rsync -X a b $ attr -l b Attribute simple.attibute has a 14 byte value for b add tar, zip to the list I still have to implement this. maybe start without additional metadata, but xattrs must not reach user systems Nope. I really think extended attributes is the way to go. There is also an XDG standard for extended attributes [1]
Re: Moving Baloo forward
On Dienstag, 21. Januar 2014 13:37:29 CEST, viv...@gmail.com wrote: And windows? HPFS/NTFS has xattr support (through alternative data streams) and WINNT supports handling xattr on FAT as well. The problem about xattr is rather that 99% of all ext3/4 users will atm get setfattr: filename: Operation not supported ie. xattr nowhere being activated. This would have to change dramatically in order to make a xattr implementation useful. Next thing is global xattr awareness, ie. one has to consider that even if kio/dolphin would have great xattr support and cp aliasing -a by default etc., the user might move/copy the data using nautilus or some other lousy filemanager :-P I *do* consider xattr the BY FAR more sane approach to the problem, but currently do frankly not see this on end user desktops :-( Linux/Desktop has to become a xattr OS before relying on it - thus imo xattr support could only be explicitly optional to get there. Otherwise ubuntusers™ will complain loosing their metadata all the time. Unfortunately this isn't MacOS where SJ. just said: do or you're fired, you censored! Keeping metadata in id3v2/xmp/iptc unfortunately only covers few filetypes (w/o invoking sidecars, ie. what __MACOSX does when entering the outer world) - directories could be stored in .directory Cheers, Thomas
Re: Moving Baloo forward
On Tuesday 21 January 2014 12:32:29 Todd wrote: Would it be possible to store the metadata inside files that support it (like images or music files) and use xattrs only for files that don't have their own internal metadata format? Well, anything is possible. Someone would just need to implement it. We had wanted to do something similar during the Nepomuk days as well, but it didn't quite materialize. -- Vishesh Handa
Re: Moving Baloo forward
On Sun, Jan 19, 2014 at 11:44 PM, Albert Astals Cid aa...@kde.org wrote: http://community.kde.org/Baloo/NepomukPort misses lots of stuff of plasma-mobile, share-like-connect, rekonq, ktp, tellico. KTp is already ported for some time now :) Cheers -- Martin Klapetek | KDE Developer
Re: Moving Baloo forward
Hi Vishesh, 2014/1/17 Vishesh Handa m...@vhanda.in http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? I experimented a bit with Conquirere and its possible port to a sql like database. While it is possible, it means I need to change a lot (depended solely on Nepomuk for this one) At the end, without Nepomuk, Conquirere is just KBibTeX which is part of KDE too. Thus I would rather see KBibTeX expanded to pdf/project like behavior rather than putting a lot of effort into copying something that exists, is well testen and widly used already. The Webminer will be ported though, as it can be simply used without nepomuk if applications just want to fetch data and save the data in their own database.
Re: Moving Baloo forward
On Sunday 19 January 2014 14:44:01 Albert Astals Cid wrote: http://community.kde.org/Baloo/NepomukPort misses lots of stuff of plasma-mobile, share-like-connect, rekonq, ktp, tellico. Added Found in http://lxr.kde.org/search?filestring=string=nepomuk Can you please find out about them and add the information? Not found there but found by grepping my 4.11 branch of kde-workspace, nepomuksearch runner, containmentactions/switchactivity, dataengines/metadata. I am interested what is your plan for kde-workspace since it's frozen at 4.11. I will provide a Baloo runner. The metadata dataengine can die. It uses Strigi internally, and just uses Nepomuk for tags, ratings and comments. If someone really has a huge objection then I can provide a similar Baloo dataengine. The SwitchActivity does not use Nepomuk. It just has a variable called useNepomuk which doesn't do anything with Nepomuk. Also are you sure you can finish all that in 5 weeks? I can finish all the applications that are part of KDE SC for sure. This involves - 1. Dolphin 2. KDEPIM 3. GwenView The rest, no. I doubt I can do it all. -- Vishesh Handa
Re: Moving Baloo forward
On Monday 20 January 2014 23:17:26 Albert Astals Cid wrote: El Dilluns, 20 de gener de 2014, a les 19:08:41, Vishesh Handa va escriure: On Sunday 19 January 2014 14:44:01 Albert Astals Cid wrote: http://community.kde.org/Baloo/NepomukPort misses lots of stuff of plasma-mobile, share-like-connect, rekonq, ktp, tellico. Added Found in http://lxr.kde.org/search?filestring=string=nepomuk Can you please find out about them and add the information? Not found there but found by grepping my 4.11 branch of kde-workspace, nepomuksearch runner, containmentactions/switchactivity, dataengines/metadata. I am interested what is your plan for kde-workspace since it's frozen at 4.11. I will provide a Baloo runner. In which repo? The main baloo repo. Unless you think some other repo would be appropriate? The metadata dataengine can die. I'd prefer not to kill stuff from the repo of something we are calling LTS, maybe just add a disabled by default compile flag? Well, I cannot port the metadata engine to Baloo. I can write a new one if required. Cheers, Albert -- Vishesh Handa
Re: Moving Baloo forward
On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. I'm concerned about the portability aspect of Baloo. It seems to rely heavily on certain API (fgetxattr) while not testing for the availability of that API. From a let's see if this stuff can build perspective it'd be nice if it gave a (better) hint about missing xapian, along the lines of what most KDE modules do when a required dependency is missing (is that macro_log_optional_feature?). Some files still have the boilerplate one line to give ... in the copyright header, too. [ade]
Re: Moving Baloo forward
On Sat, Jan 18, 2014 at 1:53 PM, Jonathan Marten j...@keelhaul.demon.co.ukwrote: Vishesh Handa m...@vhanda.in writes: http://community.kde.org/Baloo Thanks for producing that useful page, and of course for all your past and current work on Nepomuk and Baloo. There is one statement there that makes me a little concerned: This metadata is now stored with the extended attributes of the file instead of storing it in a separate database. Am I right in assuming that this means xattr? If so, would there be implications for cases where those extended attributes may not get preserved or are not supported: - simple copy/move of a file using cp/mv (with the default options) - copy/move of a file using KIO - network file systems (NFS or SMB) - backup/restore - FAT filesystems - platforms other then Linux Hoping that none of those will make normal use impossible, but if there would be problems or workarounds needed with any of these then they ought to be addressed early. Vishesh, what about these^ ? I've seen the same concerns raised on the digikam ML. Cheers -- Martin Klapetek | KDE Developer
Re: Moving Baloo forward
On Saturday 18 January 2014 12:53:38 Jonathan Marten wrote: Vishesh Handa m...@vhanda.in writes: http://community.kde.org/Baloo Thanks for producing that useful page, and of course for all your past and current work on Nepomuk and Baloo. There is one statement there that makes me a little concerned: This metadata is now stored with the extended attributes of the file instead of storing it in a separate database. Am I right in assuming that this means xattr? If so, would there be implications for cases where those extended attributes may not get preserved or are not supported: - simple copy/move of a file using cp/mv (with the default options) - copy/move of a file using KIO - network file systems (NFS or SMB) - backup/restore - FAT filesystems - platforms other then Linux Hoping that none of those will make normal use impossible, but if there would be problems or workarounds needed with any of these then they ought to be addressed early. Hey The idea is that in systems which do not support xattr a secondary database will be used to store the information. So, it will be very similar to the situation we had with Nepomuk. I still have to implement this. Regards, Jonathan -- Vishesh Handa
Re: Moving Baloo forward
El Divendres, 17 de gener de 2014, a les 17:50:38, Vishesh Handa va escriure: Hey Albert Thanks for sending this email. On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: Hi guys, seems we have reached a kind of impasse regarding what to do with Baloo and Nepomuk. Since the 4.13 freeze is coming sooner than you think (less than 6 weeks) I'd like to try to get it moving again. Here comes my proposal: Create a wiki where you clearly explain: * What is Baloo * Why Nepomuk is unfixable * What's the strategy of migrating Nepomuk data to Baloo * Can Nepomuk and Baloo run together? If so does data flow both ways? No way? One way? * For each application that we know uses nepomuk - Is it going to be ported? When? - If not ported can it still run the same with nepomuk installed? - If not ported what's the harm if nepomuk is not installed? * What is the support plan for Baloo based in kdelibs4 once KF5 is released? I guess that most of the answers can be extracted from the emails of the discussion, but having a central place that people can go and read surely helps. http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? http://community.kde.org/Baloo/NepomukPort misses lots of stuff of plasma-mobile, share-like-connect, rekonq, ktp, tellico. Found in http://lxr.kde.org/search?filestring=string=nepomuk Can you please find out about them and add the information? Not found there but found by grepping my 4.11 branch of kde-workspace, nepomuksearch runner, containmentactions/switchactivity, dataengines/metadata. I am interested what is your plan for kde-workspace since it's frozen at 4.11. Also are you sure you can finish all that in 5 weeks? Cheers, Albert Now my personal opinion is that unless some of the answers are catastrophic (i.e. something like It will eat all your data) we should move to Baloo as soon as possible. For me the situation is this: * I accept the domain experts opinion that Nepomuk is unfixable * That means we need a replacement, Baloo * Baloo is [almost] ready * Baloo will have bugs (as all software does) Now with this situation we can do two things: * Move to Baloo as soon as possible * Move to Baloo sometime in the future (let's say 1 year) If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. On top of that we have the possibility that the Baloo guys have lost motivation Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. What do you think? A huge +1. I've sent an email to the kde-promo team asking them to help me with the article. Given that we're clearly informing the world - Do not upgrade if you want to continue using Nepomuk, it does not make sense to still ship the Nepomuk KCM and kioslave. I will be removing them from kde-runtime.
Re: Moving Baloo forward
Vishesh Handa m...@vhanda.in writes: http://community.kde.org/Baloo Thanks for producing that useful page, and of course for all your past and current work on Nepomuk and Baloo. There is one statement there that makes me a little concerned: This metadata is now stored with the extended attributes of the file instead of storing it in a separate database. Am I right in assuming that this means xattr? If so, would there be implications for cases where those extended attributes may not get preserved or are not supported: - simple copy/move of a file using cp/mv (with the default options) - copy/move of a file using KIO - network file systems (NFS or SMB) - backup/restore - FAT filesystems - platforms other then Linux Hoping that none of those will make normal use impossible, but if there would be problems or workarounds needed with any of these then they ought to be addressed early. Regards, Jonathan -- Jonathan Marten http://www.keelhaul.demon.co.uk Twickenham, UK j...@keelhaul.demon.co.uk
Re: Moving Baloo forward
On Fri, Jan 17, 2014 at 1:47 AM, Albert Astals Cid aa...@kde.org wrote: Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. What do you think? Sounds like a plan to me. +1 Cheers -- Martin Klapetek | KDE Developer
Re: Moving Baloo forward
On Friday, 2014-01-17, 01:47:17, Albert Astals Cid wrote: If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. Isn't there also the option to switch selected applications to Baloo now and others later, e.g. on their respective maintainers schedule? For example move KDE PIM to Baloo, which I think we have agreement on internally, and migrating our data in the process. That should not create any issues since it is unlikely that anyone was accessing our data directly through Nepomuk instead of using our APIs. That should give Baloo and its APIs a lot of testing, almost certainly improve the situtation for us (KDE PIM), but neither touch anyone else's semantic data nor interrrupt their technology stack (as a bonus move load away from their stack). There might be other examples of apps that can safely move without affecting any other current user of Nepomuk. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
Hey Albert Thanks for sending this email. On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: Hi guys, seems we have reached a kind of impasse regarding what to do with Baloo and Nepomuk. Since the 4.13 freeze is coming sooner than you think (less than 6 weeks) I'd like to try to get it moving again. Here comes my proposal: Create a wiki where you clearly explain: * What is Baloo * Why Nepomuk is unfixable * What's the strategy of migrating Nepomuk data to Baloo * Can Nepomuk and Baloo run together? If so does data flow both ways? No way? One way? * For each application that we know uses nepomuk - Is it going to be ported? When? - If not ported can it still run the same with nepomuk installed? - If not ported what's the harm if nepomuk is not installed? * What is the support plan for Baloo based in kdelibs4 once KF5 is released? I guess that most of the answers can be extracted from the emails of the discussion, but having a central place that people can go and read surely helps. http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? Now my personal opinion is that unless some of the answers are catastrophic (i.e. something like It will eat all your data) we should move to Baloo as soon as possible. For me the situation is this: * I accept the domain experts opinion that Nepomuk is unfixable * That means we need a replacement, Baloo * Baloo is [almost] ready * Baloo will have bugs (as all software does) Now with this situation we can do two things: * Move to Baloo as soon as possible * Move to Baloo sometime in the future (let's say 1 year) If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. On top of that we have the possibility that the Baloo guys have lost motivation Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. What do you think? A huge +1. I've sent an email to the kde-promo team asking them to help me with the article. Given that we're clearly informing the world - Do not upgrade if you want to continue using Nepomuk, it does not make sense to still ship the Nepomuk KCM and kioslave. I will be removing them from kde-runtime.
Re: Moving Baloo forward
On Friday 17 January 2014 17:50:38 Vishesh Handa wrote: Hey Albert Thanks for sending this email. On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: Hi guys, seems we have reached a kind of impasse regarding what to do with Baloo and Nepomuk. Since the 4.13 freeze is coming sooner than you think (less than 6 weeks) I'd like to try to get it moving again. Here comes my proposal: Create a wiki where you clearly explain: * What is Baloo * Why Nepomuk is unfixable * What's the strategy of migrating Nepomuk data to Baloo * Can Nepomuk and Baloo run together? If so does data flow both ways? No way? One way? * For each application that we know uses nepomuk - Is it going to be ported? When? - If not ported can it still run the same with nepomuk installed? - If not ported what's the harm if nepomuk is not installed? * What is the support plan for Baloo based in kdelibs4 once KF5 is released? I guess that most of the answers can be extracted from the emails of the discussion, but having a central place that people can go and read surely helps. http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? Reading it from a outside-world-communication perspective :d Now my personal opinion is that unless some of the answers are catastrophic (i.e. something like It will eat all your data) we should move to Baloo as soon as possible. For me the situation is this: * I accept the domain experts opinion that Nepomuk is unfixable * That means we need a replacement, Baloo * Baloo is [almost] ready * Baloo will have bugs (as all software does) Now with this situation we can do two things: * Move to Baloo as soon as possible * Move to Baloo sometime in the future (let's say 1 year) If we move now, in one year we will have had 1 year of real usage uncovering bugs and 1 year of bugfixes. If we move in one year, we will have lost that 1 year of real usage (since few people will be using it) and so in one year we will be in the same situation as we are now. On top of that we have the possibility that the Baloo guys have lost motivation Thus my suggestion is that after we get the wiki done and we explain clearly the situation as Thomas Lübking suggested (i.e. if you really really really really need what Nepomuk provides and can't accept a single regression in that field, do not upgrade), we go ahead with moving to Baloo instead of Nepomuk. What do you think? A huge +1. I've sent an email to the kde-promo team asking them to help me with the article. Will help where I can. Given that we're clearly informing the world - Do not upgrade if you want to continue using Nepomuk, it does not make sense to still ship the Nepomuk KCM and kioslave. I will be removing them from kde-runtime. signature.asc Description: This is a digitally signed message part.
Re: Moving Baloo forward
On Friday 17 January 2014 17:50:38 Vishesh Handa wrote: On Friday 17 January 2014 01:47:17 Albert Astals Cid wrote: I guess that most of the answers can be extracted from the emails of the discussion, but having a central place that people can go and read surely helps. http://community.kde.org/Baloo Could someone please prooof read this page and let me know where it can be improved? It would be useful, if the #Porting_your_Application section would contain some link to the actual porting instructions/example code, or at least some API documentation link. Remaining applications can get ported faster this way. Christoph Feck (kdepepo) KDE Quality Team
