Hi,
On Wed, 2008-11-19 at 08:48 -0600, Carsten Neumann wrote:
> Hi Gerrit,
>
> 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.
For the caching mentioned above. This I actually find important enough
that we should think about putting it into the OpenSG infrastructure.
> 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. Only the
individual file handlers have to make sure this still works with MT.
kind regards,
gerrit
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
