Features/data reporter

[dandm1]

A refactor of the pull request with stub functionality for DataReporters. Now consistent with the extensions model.

[dandm1]

The one thing I wasn't clear on from the code base so far is how you intended for the bits of the application to hang together.

I was thinking that a bunch of effectively independent services that have their own timers & schedules and are held together by lockable shared data objects could be quite an elegant architecture. My plan therefore was to pass a WeatherStation object to each publishing service when the service is started - with the schedule defined by the settings. The publisher is then responsible for pulling the data from the station each time its timer triggers.

That said, there would be a lot less multi-threading problems with a main message pump that goes (metacode):

While !(Ctrl-C)
{
    var currentData = station.ReadData();
    foreach(var publisher in publishers)
        if (timer.now() > publisher.NextPublication)
            publisher.DoReport(curentData)
    Thread.Sleep(A while)
}

Is that what you had in mind?

[Jasonkingsmill]

The one thing I wasn't clear on from the code base so far is how you intended for the bits of the application to hang together.

I was thinking that a bunch of effectively independent services that have their own timers & schedules and are held together by lockable shared data objects could be quite an elegant architecture. My plan therefore was to pass a WeatherStation object to each publishing service when the service is started - with the schedule defined by the settings. The publisher is then responsible for pulling the data from the station each time its timer triggers.

That said, there would be a lot less multi-threading problems with a main message pump that goes (metacode):

While !(Ctrl-C)
{
    var currentData = station.ReadData();
    foreach(var publisher in publishers)
        if (timer.now() > publisher.NextPublication)
            publisher.DoReport(curentData)
    Thread.Sleep(A while)
}

Is that what you had in mind?

I had intended there to be essentially 3 main task branches of the application:

• Web service
• Station Service
• Scheduler

The web service is pretty self explanatory, current data display/configuration etc... The Station Service is really just a The scheduler (based on Quartz.Net) would then handle everything else:

• Weather Data Logging points
• Data reporting (ftp report, custom web service report, etc..)

In the case of DataReporters, I guess it's not much of an issue if the currentData is supplied, or some other service is supplied (possibly a subset of the existing IWeatherData interface...) to allow the extension to fetch data for itself. Although there may be some merit in supplying station meta also - I haven't looked very deeply into the use-cases of the data reporters yet. I guess, logically similar to your code sample.