2011/3/30 Dena Dragos <[email protected]>: > Hello! > >> You obviously put a good effort on that proposal, congrats. > > Thanks :). > >> But I'm worried about the probability of accomplishing this proposal >> considering this is only the architecture. The way I see your >> proposal, I would argue that it is better to focus on one of its >> elements: Umit Agent Daemon. This actually is your main element, if >> I'm not mistaken. The UI is very important but if this other piece >> doesn't work well, I don't think the UI will be able to compensate for >> it -- what I'm trying to say here: don't worry too much (yet) about >> the UI if you can do a good project on this daemon. > > 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. > >> The last Figure on your proposal seems to propose a way too big >> daemon. If you had 10 monitoring modules, would they all be inside >> every daemon ? That doesn't seem right to me. Maybe each daemon is >> different from the other, but this doesn't seem clear based on your >> proposal. Also, the argument of running each monitoring module in its >> own thread didn't (and other parts that involve threads) didn't seem >> totally necessary -- some form of pooling or asynchronous >> notifications wouldn't be enough ? > > 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" ? > With this basic set-up the agent can be running > and share the needed information while also being pretty lightweight. > On hosts which the agents are running there can be an Umit process > running to show the information gathered from the local agent, but > that is optional also. Most likely you will be running Umit Network > Scanner just on one host to show the information gathered from all the > agents in the network or even remote agents if configured so. At the > same time you could install the Umit Network Scanner on another host > where an agent is running and get similar information (not exactly the > same based on the configuration). And I think it would be also cool to > be able to get information directly from agents which aren't installed > on the local host (that would require configuration of course). Yes, that is what I imagined based on the current architecture. > > The monitoring modules are optional also and their main purpose is to > get network async events from other protocols rather than just using > the device sensor. Exactly what monitoring modules are running can be > configured per agent: the information gathered from them can be shared > or not to other agents. Monitoring modules should be similar to > plugins in concept. I hope I made this bit clear, because it's pretty > important in my design and I just noticed I thought some things and I > didn't wrote them :(. > >> 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. So.. I believe you have a good proposal, just keep the emphasis on your main subject. Regards, -- -- Guilherme H. Polo Goncalves ------------------------------------------------------------------------------ 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
