Hello! On Thu, Mar 31, 2011 at 1:06 AM, Guilherme Polo <[email protected]> wrote: >> Yes, the Agent Daemon is the main element, you are correct; and that >> would be my main focus also. I think I can work pretty fast with the >> UI anyway since I have some experience with GTK+ so won't have to >> study too much for that part. In any case, the front-end would be done >> after the back-end is solid. > > I didn't mean to imply that you shouldn't work on the UI at all, but > it will take a lot of time (independently of how good you are with > GTK) to do a very good UI too (again, I'm not saying that you can't do > a good UI, but it goes so much beyond putting widgets together that I > just think it might very well take more time to do it than all the > rest). Anyway, I'm happy to see you are focusing on a solid back-end.
I didn't exactly meant I will do it that fast. To be realistic, I do have my doubts I will have the final version of the UI during GSoC if I will focus on the daemon, but I plan to do a front-end anyway even if it's not going to be as smooth as it could be. From my point of view changing the UI isn't as complicated if the back-end is good. Anyway, I didn't made a clear timeline yet -- working on that right now. >> On one host there will be only one agent running and each agent will >> be configured differently. It's my fault I didn't made this clear, but >> actually in the agent architecture only these components are >> mandatory: device sensor (to get information about the current station >> as configured), the communicator (to inform other agents - on other >> hosts of course), the list with the agents and the core (so the agent >> can be configured). > > Ok, that is lighter. I would consider removing the other elements from > that rectangle then. The only remaining problem I see here is that > "Device Sensor" seems to be an "Monitoring Module" that you already > have an idea of what it would be doing. Can't you simply change > "Decide Sensor" to be an "Monitoring Module" ? That would be a good idea actually. The way I seen it originally is that the "Device Sensor" would be by default installed and enabled to provide the standard expected information from an Agent. The other modules would have been used to extend the standard functionality. But I guess it would be better if that could be turned off to leave a really light Agent which would eventually only be used to forward information. I thought the Device Sensor would be a bit different from the other Monitoring Modules since it's used to gather information from the local host while the modules listen for network events trough protocols like SNMP. But obviously, my thought wasn't exactly brilliant as there isn't any good reason for which I considered the Device Sensor special compared to other monitoring modules. Going to change that in my design, thanks for the idea! :) >>> Now about the communication protocol I would consider selecting one >>> that is relatively safe. Can't a "simple" HTTPS work ? >> >> Yes, HTTPS could do, but I was mainly referring to the format of the >> messages send by the communicators so that if you would implement a >> new monitoring module which will share a new type of information you >> shouldn't modify anything in the communicator. >> > > I honestly think that the main point here is to use one well > stablished protocol and keep your own "sub-protocol" simple. Evolve > over time as needed. Yes, was just trying to figure out what fields would be required in my sub-protocol so I can keep it simple and extensible. Going to work at that myself anyway. I would one addition question though: Any suggestions on how the discovery of the agents in the network should work? It's pretty unclear for me with my current networking knowledge, but if the agent is supposed to listen on port X and that specific port is used by another TCP connection before the agent starts what would be the back-up plan? Or it could work by just sending messages to all the open ports on a host to see if there is an agent listening on those ports. Best regards, Dragos Dena ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Umit-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/umit-devel
