Il giorno Wed, 14 Sep 2016 23:29:22 +0200 (CEST) Christoph Cullmann <cullm...@absint.com> ha scritto:
> CC'd Vishesh, perhaps I am wrong with that issues and misunderstand > the code, unfortunately e.g. the database structure is not that well > documented, if I don't just not find the correct docs in the git. While perhaps it's strong to write "scrap", I believe this is a potentially useful Framework which (along with KFileMetadata) extremely badly documented. I don't mean to bash its maintainer here, I say it as a statement of fact: in order to implement KFileMedadata in my own application, I had to scavenge the source code to understand how to use it, and there were close to 0 API docs. As discussed with Cristoph last night on IRC, I would suggest to use this case to ensure that, in the future: a. Only allow frameworks with at least a maintenance commitment promise b. Only allow frameworks with at least their main classes properly documented. c. Only allow frameworks with adequate test coverage (more unit tests would have uncovered some of the problems here?) > 4) fundamental problems like: wrong data structure for index (32-bit > inodes in 21th century?) and close to zero docs what it does > internally I assume this won't be switchable easily? > Scrap baloo_file* and Co. and just reimplement the public API (modulo > the settings for the then non-existing indexer daemon) to use tracker. As I said yesterday on IRC, I don't oppose this if it means better maintenance. Only, please ensure things won't break, I don't want to deal with the angry mobs in the forum. ;) > => Opinions? It would be nice to hear what Vishesh, Pinak and Boudhayan think about this. -- Luca Beltrame, Ph.D. Translational Genomics Unit, Department of Oncology IRCCS Istituto di Ricerche Farmacologiche "Mario Negri"
pgpuoh7i0UqTW.pgp
Description: Firma digitale OpenPGP
