On Wed, Apr 29, 2009 at 12:50 PM, Steven Truppe <[email protected]> wrote: > i have a question about the configuration context, when i run my CS project > (debug build and started with --verbose) i get the following: > SCF_NOTIFY: scanning plugin directory: > D:\build\mywork\CPP\CS\BsApplication\msvc-cs-1.4\Debug (context `app'; > recursive no) > SCF_NOTIFY: scanning plugin directory: > D:\build\mywork\CPP\CS\BsApplication\msvc-cs-1.4\Debug\plugins (context > `crystalspace'; recursive no) > What are the different context types for?
The context is an arbitrary identifier. It exists primarily for detection of installation or configuration problems. If an SCF plugin identifier is encountered multiple times within the same context during detection scanning, SCF raises a warning. This might happen, for instance, if you have one version of CS (say 1.4) installed and are working with a locally built CS (say 1.9). If you have not taken steps during testing of 1.9 to ensure that plugin scanning only looks at the locally built 1.9 plugin directories, your test might also encounter the installed 1.4 plugins. Since the order of plugin scanning within a context is essentially indeterminate (that is, it is an implementation detail), you can't know which plugin actually gets loaded (in our example, the 1.4 or the 1.9 version). Mixing plugins from different versions or installations is a sufficiently serious condition that SCF warns about it. The arbitrarily-chosen "crystalspace" context is just a way to distinguish plugins which ship with CS from those which do not. Likewise, the 'app' context distinguishes plugins specific to your application. Other contexts can be invented to distinguish the origin of particular collections of plugins. Crystal Space automatically arranges for SCF to scan for application-specific and CS-specific plugins, and assigns contexts 'app' and 'crystalspace', respectively, to those two groups. An empty context name results from manually asking SCF to scan a path for plugins without giving it a context assignment for plugins discovered by the scan. Note that the above description specifically states that a warning is issued only if a duplicate is found within the same context. This means that duplicates can exist between contexts. Application-specific plugins are explicitly scanned before CS-supplied plugins, which means that applications can legally override CS-supplied functionality by providing a different implementation but with the same name as a factory-supplied plugin. This valid case does not warrant a warning, so none is issued; that is, despite having the same SCF name, they are in different contexts. (Note that in debug mode, a notification message -- not a warning -- will be issued for this case in verbose mode just as a diagnostic aid.) > Does it makes any difference in which context the plugins are loaded? And if > what's the difference? As noted, contexts are just arbitrary names primarily intended to identify installation and/or configuration problems. They do not have any functional impact. > Can i change this behavious somehow so i don't have a 'crystalspace' context > -- > so only one context for my application is there (if this makes sense at all). Since context names have no functional impact, you only would be crippling a problem-reporting mechanism by doing this. There is no benefit. -- ES ------------------------------------------------------------------------------ Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf _______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
