Re: [sensor-dev] Code checked in

[Age M. <age...@gm...>]

On 6/29/05, Richard Swart <rj...@gm...> wrote:
> Hi Age, Jurjan,
>=20
> The tree concept looks interesting and powerful (as far as I understand
> it). I suppose you want to expose this through the admin  interface (so
> we will need a tree viewer?) . In a way this makes everything a little
> bit more complicated (or advanced) a I anticipated.

I'm still doubting whether to expose (a copy of) the internal
structure to the export service (as the data model for the reporting
side) or to implement that seperately. The internals are optimized for
multi-threaded access while the reporting stuff is read-only. As I see
it now, there are three or four seperate forms of sensor data:

- Input handles from the input service (timer, Counter, Gauge). They
are simple proxies for the internal SensorData
implementations.Write-only
- the internal SensorData implementations themselves. Optimized for
multi-threaded access. Read-write
- Export data. Read-only but close to the structure of the internal
SensorData implementations
- Import Data. Write only data pulled from other systems that has to
be stored in the internals

Importers cannot just use input handles like Timer to import data into
the core. They already have the full data, which they have to convert
to some standard type and store in the core.

I'm still thinking about this stuff, Suggestions are welcome.

> I played a little bit with the plugin idea. Probably the easiest way to
> do this is to use Spring. The idea is as follows:
>=20
> - We'll have scheduled jobs per sensor type. One for Timers, one for
> Counters, one for Gauges.

Why split this up ?

> - Each job will take (through dependency injection) a list of beans that
> implements either a TimerDataExportService,  CounterDataExportService,
> ......

I would use one export service and one import service that support
export/import for all supported sensor types.

Plugins are just as important for importing data.

> - The job will iterate through the list of injected beans and will call
> getDataAndReset() and persist the data.

The scheduler can be configured with a list of plugins. These can be
importers or exporters, this doesn't matter to the plugin scheduler.
Each plugin can optionally be configured with a seperate cron
expression from the default one. The scheduler simple runs the plugins
when they ned to be run. Each plugin has a reference to either the
import service or the export service and is responsible for
transforing imported data to the correct model and exported model data
to the target system model..

> This way we can plug any component implementing one (or all) Export
> interfaces just by adding them to the spring config (probably a separate
> one just for this) . Would this be flexible enough? Any drawbacks?

See above. Obviously we will need one more service, bringing our total
list to the following:

- input service (managed, active input)
- import service (direct, passive input)
- output serivce (getting data out of the core)
- admin service (configuring and administering the core)

plus these interfaces:

- SensorDataImportPlugin
- SensorDataExportPlugin

These both extend the SensorDataPlugin interface

> As a next step I propose we focus on defining the import, export and
> admin interface. After this Age could continue to concentrate on the
> core stuff (assuming he likes that) and Jurjan and I can work on some
> other items.

Like I said above, I'm currently thinking about the interfaces that
hover around the core. Any new idea will be reported here :)

Age