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
-------------------------------------------------------------------------
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
