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. > 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). 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). 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. Thanks for your feedback! 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
