Re: [sensor-dev] Code checked in

[Richard S. <rj...@gm...>]

Age Mooy wrote:

>  
>
>>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:
>>
>>- We'll have scheduled jobs per sensor type. One for Timers, one for
>>Counters, one for Gauges.
>>    
>>
>
>Why split this up ?
>
>  
>
Because I anticipate that you want to have a different schedule 
frequency per type, but probably not per plugin. Splitting up the 
interface also means that plugins do not have to implement a sensor type 
if that does not make sense (e.g a VMdata plugin with only Gauges).

>>- 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.
>
>  
>
I still don't  see a  clear  case  for  a  push  model except for 
persisting data (which I don't see as part of the core).

>>- 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..
>
>  
>
It's more complicated than I had in mind with a separate crom expr per 
plugin. It is flexible but will also impact the gui for managing all 
these schedules, etc. Do we really need this? 

>>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
>
>  
>
But I want the core also to behave as a plugin. Can't we have the export 
interface for the core and the plugin to be the same?

>>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
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click
>_______________________________________________
>Sensor-developer mailing list
>Sen...@li...
>https://lists.sourceforge.net/lists/listinfo/sensor-developer
>
>  
>