Re: [Opensg-core] SceneFileHandler::setReadCB

[Carsten N. <car...@gm...>]

	Hi Gerrit,

Gerrit Voss wrote:
> On Wed, 2008-11-19 at 08:48 -0600, Carsten Neumann wrote:
>> Gerrit Voss wrote:
>>> On Tue, 2008-11-18 at 11:04 -0600, Carsten Neumann wrote:
>>>> 	Hi Andreas, All,
>>>>
>>> just for my understanding what do you expect to override in the top
>>> level handler ?. The specific loaders inside can already be replaced.
>> i'd like to be able to add the ability of caching things, while that can 
>> (and maybe should) be done by the app for scenes, for images it is 
>> tricky, because the loaders all go to the global ImageFileHandler. 
> 
> 
>> That's why I'd like to have SFH hold a pointer to the IFH to use and 
>> pass its "this" pointer to the loaders. The default for the IFH would 
>> simply be the global one.
> 
> but that does only require the IFH to change. 
> 
>> Maybe that is actually the bigger problem, that loaders always use the 
>> global objects instead of the ones they were called from ?
> 
> well, currently there were only the global ones, so these were identical
> to the ones they were called from.
> 
>>> A small problem I see is that it does not seem likely to scale. What
>>> do you do if project/lib A needs to use their replacement where as
>>> project/lib B theirs. I would not try to encourage this.
>> But currently you either have to hack OpenSG or use the callback 
>> functions to take over control.
> 
> yes but this is unfortunately the way things went ;-( It was just the
> easiest way out to achieve the thing needed.
> 
>> I think there are legitimate uses for extending what SFH does (Andreas 
>> mentioned encrypted streams) and deriving from it seems the better way 
>> to implement these things. 
> 
> here I slightly disagree, the better way for me would be to provide the
> infrastructure that users can register their own {en|de}cryption / 
> {en|de}compression engines instead of deriving from the global handler.
> Same goes for network or other exotic streams.

hm, that seems to go in the direction of the io redesign that is 
described on the wiki. I was shooting for something less ambitious ;)
I'll go over the wiki content on the weekend and see if I can come up 
with something and produce some code that goes in that direction.

> For the caching mentioned above. This I actually find important enough
> that we should think about putting it into the OpenSG infrastructure.

ok, I'll see if I can fit that in there somehow ;)

>> Then finally it seems nice to be able to use 
>> a derived type for the global instance, instead of being fixed to what 
>> OpenSG comes with. So basically I'm changing SceneFileHandlerBase a bit 
>> and instead of
>>
>> typedef SingletonHolder<SceneFileHandlerBase> SceneFileHandler;
>>
>> it is:
>>
>> class SceneFileHandler
>> {
>>    public:
>>      static SceneFileHandlerBase *the(void);
>>
>>      static bool destroy     (void                           );
>>      static void setSingleton(SceneFileHandlerBase *singleton);
>>
>>    private:
>>      static SceneFileHandlerBaseRefPtr _the;
>> };
>>
>> so that _the can be replaced.
> 
> Hmm, why do you still need the singleton structure at all (it is no
> singleton anymore anyway), and you plan to pass the handler pointer to
> the individual file handlers, so get rid of it. Just let the users
> create the global handler they want.
> 
> Actually a compromise would be let the old singleton structure be there
> for convenience and just pass the required pointers to the actual file
> handlers so they don't have to go to the global one. This way the users
> can start out with whatever global handler they like.

yes, that was the idea - allow creation of your own objects and keep the 
singleton just as a convenient (backwards compatible) way of getting the 
global handler.

> Only the
> individual file handlers have to make sure this still works with MT.

right, where to store state (the read/write progress, search paths, 
etc.) needs to be considered carefully. Currently an attempt to do 
parallel loading of multiple files will just stomp all over the place.

	Cheers,
		Carsten