On Wednesday 21 July 2004 3:42 am, Ted Gould wrote:
On Sun, 2004-07-18 at 12:34, Bryce Harrington wrote:
Internal - code callable directly within Inkscape,I think this is a little unclear in the document. I guess my definition of an 'Internal Extension' would be code which is in the core of Inkscape, but would like to use the extension interfaces for consistency. These would be things like SVG save, where it is built into Inkscape and will never leave, but it is easier to have it as an 'extension' and get it listed on the same menus and such.
*Nod* I think it's a good idea; having this consistency should simplify other areas as well.
When the registry is refreshed, all currently-loaded extensions should first be unloaded. When refreshed, no extensions (except for the standard defaults) should be loaded in memory.
Do we think this is that important? I don't think that it will be worth the pain to implement, it seems just as easy to me to restart Inkscape.
Hmm, well if done right it shouldn't be that hard to implement, since you'd have the per-module load/unload already. I do think it's important from the standpoint of being able to test modules as well as installing modules dynamically while the app runs. It's not a huge feature, so if it can't be done, it can't be done, but it would add a convenience that I think we will want.
Extensions may wish to persist certain values or settings selected by the user or specified at installation time.
User settings can be handled via the Inkscape Preferences system. This is particularly appropriate for setting expected to change during use and that have suitable defaults that can be used if this is the first time the user has run it. See section 7.1.6 for details on use of this system.
Installation settings are best handled by writing into the extension metadata file (*.isx, see below) during installation. These files are stored in a global location and shared by all users on the system, thus stored in a global location and shared by all users on the system, thus are appropriate for storing general defaults or values that won't change during use. This is covered in the following section.
I was thinking of this a touch differently, and it is implemented a touch differently. The idea of the preferences in the inx files is that those define what they are called, and default values, but they are stored in preferences.xml just like any other preference. I don't think that, in general, extensions should be setting up user preferences. I do think that some of the extension preferences do need to be per-file instead of global.
I'm a bit confused as to what you're saying here... Could you explain a bit more what you mean?
I know that we have discussed this in the past, but I'm curious whether we need a dependency system that is this advanced. I'm worried that it will move us into the Eclipse/Mozilla world of 'being a platform' which I'm not that interested in becoming.
I don't know if we need a dependency system, but I suspect we may. If we do implement a dependency system, though, it would probably be unwise to go half-way with it; if we're going to have something we may as well make it powerful enough to handle the usual cases (multiple-dependencies, satisfies, etc.)
Currently, this is being taken care of by the implementation section. If the implementation of a script requires another extension, it is taken care of there.
But the problem with this is that it's all run-time, and seems a bit hacky.
Now, the problem then comes with language bindings were we'd really not like to have to load the whole interpreter of a relatively unused language just to run the 'check' function.
I'm not sure what you mean by this. This wouldn't be a problem if you have dependency checking since the interpreter module would only be loaded if something actually needed it.
==== 7.1.0 Internal ====
Access to Inkscape internals is provided through the Internal classes. These classes expose APIs for various compiled-in functionality that can be used by other extensions.
The Internal functionality is grouped into different sets, as follows.
I'm not sure, we may be talking about different things here... but I think of Internal extensions like what was defined above, C code that is using the extensions interfaces to make things easier. I don't really see it as APIs. But, I think most of these APIs are probably necessary writing an extension.
Yeah, I elaborated on your concept of internal extensions. It is logical: If you allow extensions to reference and use other extensions, and if you allow internal code to be used the same way as extensions, then when you need API's for the extensions to talk to, why _not_ implement the internal functional APIs as extensions? This way you have a single calling system that's used for everything. PLUS, if you ever wish to break out internal functionality into loaded modules, you don't have to redo a bunch of interfaces - the functionality could be called in the same way regardless of whether its implemented internally or as an extension.
===== 7.1.9 Extension Manager =====
The Extension Manager Extension enables extensions such as Plug-ins to access other extensions.
acquireExtension(extension_name, extension_version, &ext_obj); releaseExtension(extension_name, extension_version);I think this is overkill also. I don't really have a problem with one effect calling another (or something basic like that). But once we get to things like publishing APIs and the such for Extensions we might as well figure out how to embed Emacs :)
Well, I did lift this concept from another extensions system, that was shooting for a pretty ambitious level of extensibility. I'm not sure I'd call it 'overkill'... 'advanced' perhaps. I do think that it is needed, though. An extension that needs to call another extension cannot blithely assume the extension is always going to be there and start making calls.
===== 7.4.0 SVG Libraries =====
Library Extensions are interfaces to collections of data files that can be queried and loaded directly into the document.
I'm not sure if this is a good use of extensions, I think that this should probably be implemented separately. I think that it is deferent enough to warrant its own implementation.
Why do you think that? You've got this very flexible system for adding new kinds of extensible functionality, why not make use of it? I'm surprised you didn't like this - it seems to fit into the concept quite well. Really, it's not that much different requesting to call a script to generate some SVG; in this case you simply request the SVG directly from file or db. Certainly the mechanisms are different, but that's the idea with Extension Implementations anyway.
Bryce