> I've just pushed the first usable version of Sequel to the > github master branch.
Nice. But why didn't it get a repository of its own? Maybe I would like to install Equalizer via apt and then hack on the Sequel source code without distraction. > Sequel provides a simple programming interface to the > Equalizer parallel rendering framework. It allows rapid > development of clustered multi-GPU application while not > sacrificing the flexibility and power of the underlying > Equalizer framework. The philosophy is to lower the entry > barrier to multi-GPU development by hiding the flexible, > but complex class hierarchy of Equalizer. Yes, this is much needed. This is obviously the right approach. But in my opinion it does not go far enough. I am not sure whether it is a good idea to hesitate the use of some good programming guidelines just for the sake of consistency. Is there a strong reason for not using RAII? If you want to provide a narrow interface instead of exposing a bunch of classes, maybe it would be a good idea to seperate (public) headers that provide this interface from the rest of internal source files? > Right now a lot of things are missing, and I'm counting on > the community to provide input on what is needed. You can > help by using Sequel for your development, either of new > applications or existing Equalizer programs. I will. > The API documentation can be found here: [link]. I'll > update the remaining documentation and website > incrementally during the next weeks. I find it confusing that the API reference contains the examples. Any good documentation contains examples as well as a reference. But there should be a clear distinction. ---- wishlist: * Don't provide any 'init' functions. * Don't provide any 'exit' functions. * Use smart pointers (smarter than co::base::RefPtr!) * Don't force clients to provide 'destroy' functions. * Don't provide boolean return values indicating success/failue. Classes should be initialized in the constructor and deinitialized in the destructor. Further, anything that needs to be initialized and/or deinitalized should be wrapped in a class. -- RAII (Really) smart pointers should be able to provide reference counting without any requirements to the pointee type (nonintrusive). It should be possible to provide a custom delete function. Qt windows then could be created like this: return shared_ptr<QWindow>(new QWindow(), bind(&QWindow::deleteLater, _1)); Calling multiple functions each of which provides a boolean result value requires a cascade of if-not-successful-then-bail checks. Using exceptions here can simplify both library and client code by a great deal. cheers, Daniel _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
