I've sliced and diced some with internal comments. I'm very excited that this got written.
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.
Inkscape will have a command accessible from its menus for reloading the entirety of the registry. This provides a mechanism for the user to access newly-installed extensions without needing to restart Inkscape.
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.
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 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.
Every Extension must have a definition file, *.isx. Inkscape loads these files during initialization (and subsequently as requested) to learn what extensions are available to it. The file is an XML format with a top-level element 'inkscape-extension', which contains the following sub-elements:
name - required id - required version - required deps - optional; lists the dependencies type - "input", "output", etc. impl - "internal", "script", "plug-in", etc.The deps section contains a list of elements that indicate pre-requisites for use of the extension. For instance, it may require that other extensions be present, or require a certain version level of internal functionality, or require the presence of a certain file in the file system, or require a certain service be active like a database or mail service. Each dependency can also be marked as required or optional, or if it satisfies another dependency.
Deps type - required; "extension", "file", "service", etc. id - required; the identity of the dependency it requires. E.g., 'org.inkscape.dia_import', '/etc/foo.conf', 'mysqld' version - optional; a simple regexp pattern used to find if the available version is sufficient to satisfy the dependency required - if present, the dependency is required; if not present, it's treated as an optional dependency satisfies - optional; gives a list of other deps that it will satisfy. For instance, either 'postgres' or 'mysql' could satisfy a 'sql_database' dependency.
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.
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.
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.
==== 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.
===== 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 :)
===== 7.3.2 Plug-in Initialization Algorithm =====
This looks fine for now, but I think when we get to implementing this we should probably use the g_module interface in glib.
===== 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.
Cool. That's my initial set of comments, I think there are various topics here that need to be discussed. Bryce, thanks for bringing them up!
--Ted