> On Oct. 24, 2015, 6 p.m., Vishesh Handa wrote: > > I still have many thoughts regarding this particular approach, and third > > party plugins in general. I'm trying to write them into a cohesive blob.
Do you mean the entire current extractor interface, or just this patch? What do you mean, "write them into a cohesive blob"? Do you mean all the plugins would be compiled into one giant SO/DLL? I wrote this patch because it was a 4-hour job, but if you want to overhaul the entire plugin API I suppose the SOC project would be a better place to do it. > On Oct. 24, 2015, 6 p.m., Vishesh Handa wrote: > > src/extractors/externalextractor.cpp, line 69 > > <https://git.reviewboard.kde.org/r/125762/diff/4/?file=412432#file412432line69> > > > > Why move from the C++ for syntax to Q_FOREACH? There doesn't seem to be > > any advantage in this case. I was told on IRC (IIRC, by Luca Beltrame) that we still can't use range-based for loops in frameworks because of compiler requirements. My initial patch used range-based for loops. - Boudhayan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125762/#review87334 ----------------------------------------------------------- On Oct. 24, 2015, 5:49 p.m., Boudhayan Gupta wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125762/ > ----------------------------------------------------------- > > (Updated Oct. 24, 2015, 5:49 p.m.) > > > Review request for Baloo, KDE Frameworks, Pinak Ahuja, and Vishesh Handa. > > > Repository: kfilemetadata > > > Description > ------- > > This patch introduces support for external metadata extractors in > KFileMetaData > > The external extractors themselves can be written in any language, provided > that it can be executed as a standalone executable (compiled or script with a > hashbang), with command line arguments, and can output data to stdout. > > The extractors are executed like so: > > * `extractor --mimetypes` - outputs a list of mimetypes supported by the > extractor, one per line. > * `extractor filename` - outputs a json document with the metadata. The keys > are such that they can be directly used with PropertyInfo::fromName(). > > At the KFileMetaData end, an additional internal plugin (ExternalExtractor) > is provided that forms a conduit between external extractors and the internal > API. This plugin looks for executables called > kfilemetadata_extractor_<something> in /usr/bin to find external extractors, > and executes them with the --mimetypes arg to find the list of mimetypes each > extractor supports. ExternalExtractor then claims to support all of these > mimetypes, and then delegates to the extractor executable when doing the > actual extraction. > > > Diffs > ----- > > README.md 19b1a26 > src/extractors/CMakeLists.txt 5dd223e > src/extractors/externalextractor.h PRE-CREATION > src/extractors/externalextractor.cpp PRE-CREATION > > Diff: https://git.reviewboard.kde.org/r/125762/diff/ > > > Testing > ------- > > Tested with the sample executable file extractor (as attched, written in > python) with the dump manual test in KFileMetaData. Works. > > > File Attachments > ---------------- > > kfilemetadata_extractor_executable > > https://git.reviewboard.kde.org/media/uploaded/files/2015/10/23/146b657f-31d9-4117-a82f-ef966a6339d4__kfilemetadata_extractor_executable > > > Thanks, > > Boudhayan Gupta > >
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
