On Wed, May 03, 2006 at 05:05:39PM +0100, David Squire wrote: > Wolfgang Müller wrote: > >Thanks for your quick answer. > > > > > >>I take you point, but this is something that I am quite likely to have > >>time to look at - on the scale of "some time this year". If we are to go > >>down that path, we need to kick around some ideas on how we would like > >>such a system to work. > >> > > > >I have thought about this. After my experience with c libraries as > >plugins, I am a bit weary. Some recent problems we had are still related > >to plugins. People have to versions of a lib floating around, and libtool > >picks the wrong one. > > > >I would suggest that the feature extractors are programs that read from > >stdin a list of urls and output a list of file locations via stdout. After > >indexing, these locations are fed to something that aggregates the > >indexing data and adjusts the config.
i would disagree. ;) i think the URL centricness of gift has been a pain, to me. i've had to hack up my Client.php to re-write some URLs. then again, i may be misconfigured. however, i like the present method of the feature extractor. if i were to make a change, i'd work on a batch mode. unix utilities are commonly written to accept input on stdin, and output on stdout. if i were to make a modification to the feature extractor, i'd make it perform as that, then you dont need a "plugable system". the only change i ever made to switch between my version and yours was in gift-add-collection.pl, to change the executable name. to me, it seems ideal to ship multiple 'feature extractors', and pass the name of the feature extractor to use to gift-add-collection.pl the "isolated nature" of the feature extractor code is part of what let me make these improvements. i'm no c++ programmer. ;) > > > >This would be slightly hackish, but fast and flexible and it would be > >low-impact on the code. mine would be more hackish, but "fits better" with unix philosophy. > > > Yes. I agree that this seems a sensible approach. I would also be keen > to see some MRML extensions to support some basic descriptions of the > feature groups that go with a collection, most importantly the way > similarity should be calculated for the feature group (e.g. histogram > intersection, Euclidean distance, tf.idf, etc.) > > It would be good to think about this over the next few weeks/months. I > think an extension in this direction would really improve the usability > of the framework (cf. the "symbols discussion earlier today). There > could be a default set of provided similarity calculators (based on what > is already there), and perhaps a provision for users to provide others > (possibly plugins again, but perhaps also by providing subclasses and > editing a nice clear source file that delegates these things). > i'm excited to hear about this. ;) Julia Longtin <[EMAIL PROTECTED]> _______________________________________________ help-GIFT mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gift
