On Tue, 2009-01-13 at 17:42 -0800, Krzysztof Kosiński wrote:
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.
Of course, I think that is a good idea.
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
Well, if you go back on the Sodipodi archives you'll notice that I fretted about this for a while. It's not clear what the right answer is. For the most part, the larger implementations all implement most of the functions. The smaller (internal) implement just a few. So what's the overhead in the two cases?
In the large single object case we end up with a few extra function pointers that never get used. Let's say an extra 100 bytes of RAM per extension. On the other hand, we burn a lot of extra objects for things like XSLT which will have to create a meta object and have dual inheritance to work right. The complexity overhead is much greater along with the bytes that are wasted on a per object basis.
I'm not sure that there is a clear winner here, but in general, I try to choose simplicity. And the large object was MUCH simpler when doing this is GObject before the whole G_DEFINE_TYPE days.
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.
Sure, that's a more standard way to do it. I'm not sure of the gains, but why not, shouldn't be any different.
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.
I figured an easier change would be to just get the local filename from GIO because it's gotten by setting up a FUSE filesystem. This would take less code change (less bugs) and I'm not sure that there'd be any more gain.
--Ted