Hi Jan,
jan p. springer wrote:
>
> after minor thinking i guess char* do have a merit. boost::tokenizer f.ex.
> uses them in the separator description. i think before applying such a
> heavy change the cost of repeatedly constructing empty (and not so empty)
> std::string's should be investigated; or perhaps someone already did?
Given that it's not a recursive or heavily used interface I'm not
worried about that, honestly.
> i also see that this puts a "heavy burden" on each single loader
> implementation
> by being required to check file existence, opening, seeking, and closing. it's
> nice that SceneFileHandler takes something here off the shoulder of both the
> library implementor and the application developer.
That's on purpose. IMHO it should be simple to write/add a new loader.
If there is complexity it should be handled in a central location and
only once.
> what i would like to be able to achieve here could be called separation of
> concern. as long as i'm in control of the source and also knowledgeable of
> the structure of an application i can probably live with SceneFileHandler and
> GraphOps as they are. in the instant where i try to experiment with certain
> inputs (or worse are stuck with some student hack that my boss absolutely
> wants
> to show to some suit) i do want to have a fine grained control from the
> outside
> (i.e. the commandline or shell) about what is happening to whom and when.
> taken
> a step further i can imagine that when using this in a larger framework where
> a prescribed application paradigm is set and i, as a developer, am only able
> to fill in certain bits there are two choices:
> 1. do as the framework gods suggest and load everything, maybe several times
Hear that folks? We've been upgraded from benevolent Dictators to Gods!
Time to party! :)
> hoping that some magic (e.g. graphops) may help in optimizing; or
> invest some extra time and effort to code a sequence of what i want to
> do
> 2. have controlling support from a lower-level layer (opensg's scene-file
> handler in that case) for describing a variety of parameters to be
> temporarily associated with a given (scene-)file.
If I understand you right, you want to be able to change things as much
as possible without changing the application. That might be an
interesting goal (hasn't come up for me yet, but I'm not the measure of
all things). I also see a different bigger picture, and that is
available scenegraph manipulation capabilities for all applications
(even the ones you can change ;). These are represented as GraphOps, so
if possible I would like to keep the GraphOps as the keeper of
functionality, and add new functionality as GraphOps.
But that doesn't preclude what you want to do. You can add GraphOps to
another application by just putting them in an .so that is loaded with
the help of OSG_LOAD_LIBS or some new plugin structure that we need to
decide on. This new GO can them register itself with the factory and
from them on it's available for the SceneFileHandler to use.
Would that allow what you want to do?
Dirk
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Opensg-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-users
