Hi Daniel, On 16. Sep 2010, at 14:35, purpleKarrot [via Software] wrote:
> IceT consists of > - the core library > - a communication library > - a bunch of composition strategies > > All parts are easily exchangeable. E.g. the default communication > library is > built on top of MPI, but you can also use your own communication > library. > > Equalizer consists of many more features, but they are all tightly > coupled > together. There is no "pay as you go" option. If you are looking for a > distributed, versioned object layer without a compositing library, > look further; > Equalizer does not provide the right solution. > > To me this "and much more ;)" does not sound like a feature, but as > a design > flaw. > > Should we address this? Should we disintegrate Equalizer into > independant > and most notably *reusable* subprojects? Their usefulness is beyond > question! Stop reading my mind. This makes me uncomfortable. Our current roadmap is: 1) Finish the API clean up for 1.0 and release it. 2) Refactor the eq::net API and library. Right now I'm stuck in 1). You'll notice a lot of @version 1.0 tags in the doxygen comments, which mark the 'official', stable 1.0 API. I have to finish this task for the remaining classes in lib/client, either by marking them @internal or @version 1.0. The compositing strategies are separated in eq::Compositor. It makes sense to refactor this, allowing for: - easy integration of other compositing libraries (ParaComp, NVidia CompleX, Ice-T) - run-time, application-specific compositing - Download-plugin-specific data types I haven't spent much cycles on this yet. You will notice that it should be very easy to build a eq::net dll, since there are no dependencies for eq::base and eq::net to the higher- level stuff in lib/client and util. The API itself needs some refactoring, e.g.: - Fall-out from RFE 2809019: Specify connection from a config file when using appNode - I'm contemplating using UUIDs as object identifiers. This ultimately eliminates the need for net::Session Furthermore there is the handling overhead in have many separate shared libraries. Ideally I'ld like to have a build option to build one Equalizer DSO or separate sub-DSO's. I'm not sure what your intent is in starting this discussion, but if you'ld like you can start working on the compositing stuff or point 2) by prepping the build system and starting to add doxygen comments and proposing concrete refactorings you deem useful. In any case, we'll eventually get to it as well. Cheers, Stefan. -- View this message in context: http://software.1713.n2.nabble.com/comparision-with-ParaView-IceT-tp4412173p5549638.html Sent from the Equalizer - Parallel Rendering mailing list archive at Nabble.com.
_______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
