Hi Fatih, On 6. Feb 2009, at 12:34, Fatih Erol wrote:
> I am considering that an equalizer monitor 'eqMon' would be useful to > implement (unless there is something in already or under development), There isn't, but it's an excellent idea. > however, I wasn't sure about some points. It would be great to get > some > pointers about the implementation, since equalizer libraries already > contain > a lot of useful basic classes : > > - First of all, it might be good to design it as not only a read-only > monitor, but also a GUI for managing and monitoring the server and > clients. > This will complicate it, of course, but it will be nice to be able > to add > interfaces/tabs for different kind of monitoring and management > tools under > the same Control Center application. Starting with Qt for UI would > be good, > I think, but maybe being extensible for GLUT could be useful for > commercial > license clashes? Qt is fine. Version 4.5 will be LGPL, which creates no license issues for us. > -- Graphically view configs, status of nodes, etc > -- Process statistics data like the statistics overlay, or other > statistics > with better visualization without affecting the rendering performance. > > > - The application should connect to interfaces on the server, and > maybe > clients. > -- So, it might be considered as an eq::net::Node for connection to > servers/clients. However, I am guessing that Node is an interface for > equalizer application nodes. Would it be better to avoid deriving > from Node, > and just make use of the Connection classes in the eq::net? eq::net::Node is meant to be generic, like all eq::net classes. You can freely use it. The online Programming Guide has a chapter explaining the eq::net layer. You are thinking of eq::Nodes, which solely use an eq::net::Node for communication. > -- Will it be better to have a different way of sending messages, > or, will > using the Command-CommandFunc be good enough? I am not sure if that > will > limit us, or the performance of the server, since we might wanna > connect > directly to the clients? Command handling as such is asynchronous and doesn't impact performance much. Be careful when you implement synchronous communications on top of it, though (cf. requesthandler usage in eq). Another way can also be the use of eq::net::Objects or eq::Objects, which allow object-based data synchronization (vs. message-based communication). > -- Do you think it would be better to have an eqDaemon class as part > of the > Nodes (server and clients) which provides multiple connection > interfaces > where the eqMon instances can connect and register for monitoring > different > data, which can run under a separate thread? (The Statistics stuff > is said > to have an effect on performance, so, keeping a daemon listening for > queries > and sending replies through a separate thread sounded more efficient) The statistics have mainly an effect because of their usage of glFinish() when they are set to nicest. I think there is no need for a separate thread or daemon. The monitor can directly attach to the server, and get other node connection information from there. > > -- ... Or, maybe have the daemon style interface on the equalizer > nodes, and > use Qt framework classes on the eqMon side? > > Please let me know of your ideas on these, as well as other > important points > that you think should be taken care of. I think it is best if you start at an external requirement specification - what should eqMon do? From thereon we can work forward to see what data and interfaces are needed. Cheers, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
