bruns added a comment.

  In D19109#414758 <https://phabricator.kde.org/D19109#414758>, @astippich 
wrote:
  
  > A few general remarks:
  >
  > - I really do not like that there are two lists of supported mimetypes now 
which have to be kept in sync
  
  
  I think this is trivial enough. Also this is covered by the unit test.
  
  > - Do we really need versioning per mimetype? IMHO it is sufficient to have 
a version number per extractor. From my experience, fixing an extractor usually 
impacts all its supported mimetypes, and rarily affects only one mimetype.
  
  Past experience tells otherwise. There have been feature extensions and 
bugfixes for specific mimetypes, just look at your own commits
  
  - "fix ape disc number extraction"
  - "implement more tags for asf metadata"
  - ...
  
  I want to reduce reindexing as much as possible.
  
  >   Also, this makes the list hard to maintain, also regarding file types 
which have multiple mime types, e.g. audio/wav and audio/x-wav
  > 
  > - Do we need an x.y version? I think a single integer is enough or what do 
you have in mind?
  
  Changes only affecting failed files are minor versions, changes affecting 
already indexed files (i.e. support for new properties) get a new major version.
  
  > - I prefer to directly construct the qvariantmap in the extractors, and 
re-use the mimetype list which is already available.
  
  Requires changing the plugin interface. Does not allow to query extractor 
properties without fully loading the plugin (which is expensive). Read 
https://vizzzion.org/blog/2013/08/ "K_PLUGIN_FACTORY_WITH_JSON or where is the 
metadata?"

REPOSITORY
  R286 KFileMetaData

REVISION DETAIL
  https://phabricator.kde.org/D19109

To: bruns, #baloo, #frameworks, ngraham, astippich, poboiko
Cc: kde-frameworks-devel, ashaposhnikov, michaelh, astippich, spoorun, ngraham, 
bruns, abrahams

Reply via email to