Greetings, Frank, > Hello Philip, hello HackyDevs, > > I have a question about a design decision that was made for sensing > mechanism of the SensorShell. As far as I see it, the SensorShell > component is not sending events to the HackyServer as son as they come > in from the sensor. Instead they are collected and transferred to the > HackyServer together every n minutes (with n > 1). > > I'm wondering if there was a reason for this, like trouble with the > HackyServer, the SensorShell's event validation or SOAP, when all > eventswere transferred immediately. > > Or is it just that HackyStat is not in need of immediate sending? > > I'm still working with a 6.4 version. Does HackyStat 7 SensorShell > support an immediate sending of events?
There are two major reasons why SensorShell 'caches' sensor data entries on the client side for N minutes before sending them all in a 'chunk': (1) Efficiency. The fixed overhead of SOAP and http associated with transmitting sensor data is quite high (on the order of seconds per transmission), while the incremental cost of an additional sensor data entry in a single transmission is very low (milliseconds). Thus, it costs about the same to send 10 sensor data entries as it does to send 1 sensor data entry. By chunking the entries, the overhead of sensor data transmission can easily be reduced by over an order of magnitude. (2) Hackystat is a non-real time system. As noted above, the overhead of connecting to the remote server, sending the data, returning the response, and so forth means that data at the client might not be available for processing at the server for an indeterminate amount of time--sometimes less than a second, sometimes 4 or 5 seconds. This nondeterminacy is a result of our choice to use SOAP/http as our transmission protocol. It means that Hackystat as a client-server system is not well-suited for applications that require real-time analysis and/or real-time coordination. For example, imagine a system that watches what you type, and then when it notices you are implementing code that violates a design pattern, it immediately pops up a window that prevents you from typing further until you indicate you really want to finish implementing that bogus code. Assuming the traditional division of responsibility of Hackystat, where analyses are on the server side, and data collection alone occurs on the client side, such a design-pattern-violation-preventer application could not be reliably implemented: there is no way to guarantee that the data could be sent to the server, analyzed, and the results made available back to the client in sufficient time to prevent the programming catastrophe. So, the answer to one of your questions is no: it is not the case that we cache and chunk the data because of some prior bugs or other issues that are no longer relevant. We do it because of the constraints imposed on us by the use of SOAP/http, and because those constraints mean that real-time responsiveness cannot be guaranteed at the level of seconds. Responsiveness at the grain-size of minutes or hours _is_ possible in Hackystat, although so far we have focussed on responsiveness at the grain-size of days (via the daily alert mechanism). One could easily imagine having sensorshell send data once per minute, and having the client poll the server once per minute for results. With this technique, for example, you could provide a continuous display of what files were being edited by all members of a project team in 'near' real-time (accurate to within 60-120 seconds). If you need responsiveness at the grain-size of seconds or milliseconds, and if you are dealing only with a single developer, the best approach is to avoid the hackystat server entirely and do everything client-side. If you need responsiveness at the grain-size of seconds or milliseconds, and if you are dealing with multiple, distributed developers, good luck. You're going to need a dedicated network protocol that guarantees delivery times. Hope this helps, and sorry I can't be more encouraging. There's little chance any of this will change in Version 7. Cheers, Philip
