Migrating to GIO for file handling means modifying the extension system rather extensively, so I think it might be worth refactoring it as well, keeping compatibility with existing extensions.
Currently there is a class for every type of extension, but they don't define much - everything of substance is handled by the "implementation" class which contains methods for everything. A subclass of it is mandatory for every extension. I understand the reason for this was to support XSLT and script extensions transparently, but I don't think this is the proper way to do it. Since each extension only provides one function (either an effect, or an input filter, etc. but not more than one of those types at a time) the proper inheritance would be e.g.: Extension -> Output -> XsltOutput Extension -> Effect -> ScriptEffect Extension -> Input -> SvgzInput
If there are common methods among XSLT or scripted extensions, those could be put in a separate class from which all other extensions implemented in this way derive (multiple inheritance). This wouldn't preclude putting more than one function/effect in the .inx file, since more than one object could be created for a given .inx file by the manager.
There should also be a proper manager object, instead of some things being done via Extension::DB (which BTW is not a singleton but a statically constructed object) and some via global functions.
GIO would be used in input and output extensions - parameters to save() and load() would be GInputStreams or GOutputStreams instead of filenames. This way extensions could save to memory and to remote locations without any special handling in the extensions themselves.
Do you have any other ideas for improvements or changes?
Regards, Krzysztof Kosiński