Hi Tanguy, On Thu, Feb 12, 2009 at 6:44 PM, Tanguy Fautre <[email protected]> wrote: > What you are describing seems to me like a convenience shortcut, but not > motivated by technical limitations. > Most of the time it's neat that this happens. But again, OSG is making too > many decisions there. Too much magic is happening, and there is no room for > customizations.
Um... there is huge room for customizations, extensions, but... I think what you are talking about stuff that is not the usual usage model of the OSG. I think you need to be much specific about your usage model. This also really isn't thread to go an hijack to talk about this type of indepth discussion. The thread was about false reports of memory leaks, not the design of various components of the OSG. > > >From what I've understood/seen, several plugins are already loaded by > >default. But why is OSG deciding what is default and what isn't? When > >needed, the application should be able to have a full control on which > >plugin get registered, and which does not. No plugins are loaded by the OSG by default. You can pre load loaded all the plugins you specifically want, you can unload any plugins when you want. > Same goes when a plugin is registered. Why does the plugin decides which file > extensions it is responsible for? It's called the ChainOfResponsibility, it allows plugins to handle many different formats, it's the plugins that know about what they can read so it make sense for them to be able to make that decision. >Why does it decide that it should be used for the whole application? It's not >the responsibility of the plugin to decide when it should be used, it's the >application's responsibility. I admit that my understanding of osgDB::Registry >is limited, but I can already sense a problem when an application would try to >load several plugins that declare themselves responsible for the same file >extensions (e.g. the Xine, the QuickTime and our FFmpeg cover pretty much the >same file extensions). You can manually load plugins in the order you wish, the first ones loaded get to handle the files first. This is the ChainOfResponsibility pattern again. You can even get the handles to the ReaderWriter's from the Registry and implement you own scheme if you wished, calling the ReaderWriter's manually yourself. > I'm using osgDB::Registry as an example, as it shows how OSG is taking > responsibilities and decisions that should be left to the applications. Um... but that's tightly coupling the application to the plugins. What happens if you want to add a plugin/NodeKit feature to an already built application? One of the most powerul features of the OSG is that you can extend it do things that are beyond what the applications specifically knows about. An instance of this is the osgEarth NodeKit that was recently release. This extends the OSG via the plugin mechanism so you can do: osgviewer myonlinemaps.earth And have it load up a earth model with streaming data being reprojected and tesselated on the fly. The same goes for all the NodeKits in the core OSG. osgviewer doesn't know anything specifically about the plugins, it doesn't even link to them yet you can still load a model containing osgVolume, osgParticle, osgText, osgTerrain nodes and the automatically everything will be loaded or you, the viewer will be extended at runtime. > The way I perceive it, OSG is using singleton most of the time as > convenience. Most applications only need one osgDB registry, so OSG > implemented it as a singleton. The plugin magic can happen transparently, and > most applications are happy. But if an application does not want the default > behaviour, it should be able to get its hands dirty. And... what is stopping you from just using the Registry to get the handles to the ReaderWriter and loaded plugins to do what you want? > By using singletons as convenience, OSG is taking too much decisions that > cannot overridden, too much magic happens behind the curtains. Exposing these > objects (e.g. readNodeFile() that takes a reference to a registry, instead of > an implicit reference to a singleton) makes the application more aware of the > objects and their semantic, and there is no more magic behaviour. It also > makes it easier for an application to override these objects (e.g. by > polymorphism) or control their states. You aren't forced to use readNodeFile(). There are facilities that even allow you to customize it - the Registry::ReadFileCallback for instance. > The fact that an application cannot manage the lifetime of OSG's globals is > in our case a major issue, and sometimes just plain wrong. So which globals are we talking about here? You can destruct the Registry and several of the other singletons by hand as mention earlier in this thread. Standardising this more would be adventurous, but it may require a singleton to do it :-) > Default convenience could be provided by an extra layer either in an extra > OSG library or by the application itself. But at least, the application gets > to make the decisions about it. I think that the C++ standard library is a > good example of such a design, where the defaults are fine for most > applications, but where an application can almost override everything if > needed. In other words, the application itself makes the decisions about the > balance between convenience and what it wants to handle. It seems you are rather deciding what the OSG can and cannot do without asking first what it can and cannot do. Perhaps quite of the few problems you've seen can be addressed already, or by simple tweaks to the core OSG. Perhaps the best thing you could do to help others understand the type of application usage you have, and what you need to the OSG to be a helping you do is to provide a simple example that illustrates the features you need from the OSG so that others can see the problems, and then can chip in with suggestions on how we might solve them. Such an example could be made part of the core osg example set and used as a reference and on going unit test for this type of usage model. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
