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.
>> 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 ;).
>> 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.
> 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.
> As a sidenote, should the reflective system contain only to/from string
> or should there be a "Variant" data type for common types
> (int/float/char/vec/matrix) as an optimization when binding to other
> languages that supports this (i.e python/java/lua)? I suggest strings as
> a start (good baseline) and move on from there if need arises. Might be
> worth a thinking though.
I would keep it at strings for now. More than that will make it much
more complicated, and I'm not sure how important it is at this point.
Dirk
-------------------------------------------------------------------------
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
