Dirk Reiners wrote: > Hi Marcus, > > Marcus Lindblom wrote: >> For 2, will the base FC-code be in a separate dll from the graphics >> stuff? If so, we are very nearly there. > > Hm, somewhat. Right now there is a lot of Base-code in OSGSystem. The > RenderTraversal currently depends on a lot of things, as the callbacks > are not decentralized yet. We might want to think about refactoring that > a little bit, once it matures. > > I'm not sure how that would make a big difference, though.
Not for the current users, no, but it would allow ppl to use OpenSG's feature for threading/clustering/distributed computing system while avoiding anything graphics related. Then again, going for that may not be worth the effort. >>> I like the run-time idea because it would automatically pick up whatever >>> extensions are loaded. Using an fcd-based preprocessor or a tool that >>> dumps stuff from the linked OpenSG lib would be a preprocess that needs >>> to be rerun whenever something changes. >>> >> Well, if you have one fcd-preprocessor you might as well have two. :) >> >> Dumping from the compiled & linked libs is ok _if_ you could emit it for >> one lib at the time, so you could ship OSGMyplugin.dll and >> OSGMyPlygin(XML/Java/Python).dll and be done with it. > > Right now I don't see how to do that. It would be possible if the FC > types had some idea which lib they're coming from (and by writing out > those things to files we could automatically find the .sos for a given > type, but that's a different story ;). Or, if you could load a lib dynamically (LoadLibrary()/dlopen()), the factory could record the FC types registered to it during load. That would work the other way around though, but it doesn't really matter. The Factory could then store the file-info in the FCClassType, to get that automatic stuff. >>> I consider those places bugs. The Field-Interface has to work >>> completely, or it's not useful, IMHO. >>> >> Is it possible to design something that works solely with data like >> that? It seems to be kind of difficult, but I'm no wizard. :) Most other >> designs I've seen tend to mask set/get-calls as simple data without >> side-effects, rather than the other way around. The set/get-pattern is >> seen in ActiveX/COM, JavaBeans, Python, etc. > > We need to keep consistency somehow, so i don't really see a way around > it. But I don't have a nice solution either. ;) Especially the fact that > we don't know what really changed, we only know what it is now, makes > handling that in changed() tricky. By 'consistency', you mean that you need changed() to run after updating multiple fields to make sure everything is ok? Yeah, we have something similar in a few places in our system. We do use set-functions everywhere, so we can handle the new/old problem somewhat locally (free old stuff in set() if needed, have changed() set up new structures.) Extending the change-lists so that the old value is stored (if requested by the FC) might be a way if it becomes a big problem? >> Making a reflective interface is good, but having it work on data and a >> changed() function seems, to me, a bit awkward and error-prone. Are >> there other succesful systems that have used that? > > I don't know. Ok. I suppose we won't have time to experiment with or change that for 2.0 anyway. :) Cheers, /Marcus ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
