https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24631
--- Comment #64 from Julian Maurice <[email protected]> --- (In reply to Kyle M Hall from comment #61) > As an FYI, the idea here is to check the database for the metadata to avoid > loading the plugin. If it's not in the database, we load the plugin and ask > it for its' metadata. When we as a plugin for it's metadata it checks > A) For metadata in it's own Perl module ( fastest ) > B) Checks the database ( second fastest, for convenience when the plugin is > already loaded, is skipped when upgrading plugins ) > C) The PLUGIN.yml file if it exists ( slowest, but these speeds are all > relative to each other ;) I am not sure if I understood that part correctly. You are saying that plugin's metadata can be in 3 different places (Perl module, database, and YAML file) now ? And in order to read the YAML file we need to load the module first ? What are the benefits ? You are talking about performance of different methods. Have you measured it ? Do we really gain that much by storing metadata in MySQL ? Have you considered caching metadata in memcache ? I thought that the yaml file would become the only source of truth and that it would allow us to avoid loading the Perl module when not needed (especially for disabled modules). I'm sorry but I really don't see what we gain here. If this is for easing parsing by external tools, then you can just dump the Perl module's metadata into a YAML file when you create the .kpz -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
