Hi Ryan, On Wed, Dec 16, 2009 at 9:43 AM, Ryan H. Kawicki <[email protected]> wrote: > It might not be convincing to have to go back to the code base and remove > these unsafe sections of code, but by having a set of documentation is really > not going to help eighty or ninety percent of the OSG community. I rarely > look at the documentation. My documentation is really just the source code > that is provided. With multiple cores available on the cheap and new and old > applications requiring database support, I feel that it is in the best > interest of OSG to have these functions removed. It will save for headaches > in the long run for you, as you will not have to explain each and every time > to use the ref version instead of the other.
I understand the principle of short term pain for long term gain... but... In the current case I'm looking towards getting the OSG users moving on to the upcoming 3.0, during this transition their will inevitably be some refactor work required by users due to the wider changes such as GLES/GL3 support, but the more pain there is the slower the uptake will be and the slower we'll sort out all the bugs/issues. In this context I want to minimize how much more pain we might introduce. The less pain the quicker people will try out and move to OSG 3.x and the quicker it's quality will improve. So right now I don't want to add any further backwards compatibility breakages if I can avoid it. >> The cache flipping trick used is not good needs to be removed. I'd be >> inclined towards use osgDB::Options to store the cache, and have an in >> memory ObjectCache to mirror the current FileCache. Such an approach >> would allow you to override the default ObjectCache to a single read >> call, such as ones done from the DatabasePager and avoid the need to >> cache flipping completely. >> > > Are there plans for this to be addressed for a future release? If so, can > you detail which release you are trying to target? I don't have any specific version for this. It's an issue right now and should be fixed a soon as I or others have time to tackle it. I would guess that it's a day or two's work. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
